How do I access data using repository in generic way

I hope I have this correct:

They way you propose to do this is not a good idea, but there are ways to achieve the same end result that are a good idea.

Take a look at this:

//Generic Factory (Reflection)
//Specify the worker and the return type
List<address> addresses = Factory<workers.address>.SelectAll<address>();
Customer customer = Factory<workers.customer>.SelectById<customer>(id);

//POCO
//Have the class do all the work
List<address> addresses = Address.SelectAll();
Customer customer = Customer.SelectById(id);
</address></customer></workers.customer></address></workers.address></address>

I use both of these. I set up my workers and models for the factory, but I use this factory within the models. If you look at Address.SelectAll() you would see the generic factory being implemented.

This is great for ease of use at run-time, but they do require some setup (ok, a lot of setup).

I have 3 tiers:

1: Data Access Level (DAL):
This is where my Entity Framework lives. I create a dbml (drag and drop tables from server toolbar, then give the tables and name decent aliases for use as a POCO), but I also create partial classes for each of the tables. Their appearance is similar. They all have internal static query and select methods that are similar.

2: Business Logic level (BLL):
This is where my factory sits. This dll is set as "Friend" of the data level dll so it can see the internal methods. It accesses these via reflection. That means that the contents of the Data structure is kept a good secret for anyone else. It cannot return the class types from the Data Level (inconsistent access et al) so there are some POCO classes that represent the original EF objects. Each object is able to convert to and from the EF object it represents.

I also have workers that are internal static, but that's only to do some more complex stuff. I didn't need to do it that way, so you don't have to worry about it.

3: The Web Interface.
I actually have an extra layer before this where I create POCOs call "Projections". These represent the models from the BLL (and once again convert to and from them), but they also access the factory and perform that work too. At this level I can play around with the data a bit more freely. I can have amalgamations of several tables data in on projection for eg. This is the simplest object to use as it does all the work itself. All the work that you have to set up.


This methods means that you have a safe, secure, adaptable and easy to use interface to you data.


There is a shortcut which is not secure:

In your EF, create the DAL as I described but make the methods public. That way you can still have the effect with none of the security. It is still safe and adaptable, but as all of the work is being done in these partial classes, they could get pretty bloated.


The idea of trying to access the table by passing strings completely bypasses the idea of EF and POCO's. You may as well use SQLClient.

I hope that helps. If not directly then maybe it help you clarify what you are really asking for? Let me know ^_^

Andy