views:

80

answers:

3

I have a class and the storage of its information is going to depend on if it is getting consumed by a web or windows application. I was going to use the factory pattern to pass out the correct object. I guess the caller would then store that object appropriately if I did not want to have recreate the object. Anybody have other suggestions on abstracting out the storage of data based on the platform?

For example I want to store data as local variables when invoked by windows app (sending out the appropriate subclass) and save in Session when invoked by web app.

A: 

Waht about handling the storage via an interface, for decoupling ?

Jhonny D. Cano -Leftware-
well there will be some data retrieval that will be the same, and am going to keep that in the base class, so dont want interface. I want to make the constructor private so it is essentially a singleton....created by the factory.
CSharpAtl
A: 

It doesn't sound to me as though the Factory pattern is a solution to the problem you have. The Factory pattern is intended to provide an instance of a particular subtype of a class, shielding the caller of the factory from (a) the actual subtype being returned, and (b) the logic which the factory used to decide which subtype to return.

This isn't what you need here. I think you need to abstract the storing of the data away from the class that models the data being stored.

You have a class common to two applications, and each of those applications should implement functionality for storing the data encapsulated by your class in a way appropriate to that application. That implies two things:

  1. Each application (web and windows form) should contain functionality to do it's storing away of data - but neither needs to include the code used by the other. e.g. the windows forms app doesn't need to know how to store data in a web session. So the code that stores the data in a web session should be in an object that is part of the web app but not part of the windows forms app, and vice versa.

  2. Given that this is the case, and given that the class who's data you're storing has to be common to both apps, that storage logic cannot be part of that class. (Following accepted OO design principles, that class shouldn't know how to store itself away in different parts of your application anyway, as that introduces dependencies that make future changes difficult. See the Single Responsibility Principle...)

Hope this is helpful

sgreeve
+1  A: 

As sgreeve says, separation of concerns is something to take into account in order to get maintainable code.

Using a repository idea, the Winform app and the Web app could inject their own storage provider. Those providers could share some common logic if needed by inheritance or composition.

public class MyClassRepository
{
    IStorageProvider _provider;
    public MyClassRepository(IStorageProvider provider)
    {
     _provider = provider;
    }

    public void Save(MyClass o)
    {
     _provider.Save(o);
    }

    public MyClass GetBy(string id)
    {
     return _provider.GetBy(id);
    }
}

The Winforms app would invoke storage through:

var provider = new WindowsStorageProvider();
var rep = new MyClassRepository(provider);
rep.Save(myClassObject);

and the Web app:

var provider = new WebStorageProvider();
var rep = new MyClassRepository(provider);
rep.Save(myClassObject);
PHeiberg
Agreed - a concrete example of what I was trying to describe. :)
sgreeve
very good point...it is the pattern I have been using all along...just got off track here...THANKS...
CSharpAtl