Entity Framework

:).. I just got carried away as this was very close to my heart.. Yes, what you are thinking is a good idea (generic factory). The Dofactory implementation IDaoFactory is very limited and breaks the OCP as well (but I guess that was for representation purpose) as any new data access would result in changes to this interface. Additionally you will find the static DataAccess class also very limited as each new entry will demand changes to this class. In fact DataAccess and DaoFactory if made generic, then you can solve the problem which you have stated. Do share your findings if you are moving in the direction which you have highlighted. That will be useful to the community members as well.

Hi Rajesh. Thanks for the reply. I have already written the DAL based on the patterns used in the design pattern framework. I started the DAL over a year ago, around the time when Linq-to-SQL was kind of being dropped by MS and they started to focus on EF. I rolled my own due to previous painful experience with strongly typed data sets and decided I wanted to stay away from GUI based data designers like those used in Linq-to-SQL and EF (although EF supports code first approach now). The issue I have now is that the abstract factory that is used to instantiate the Data Access Objects is very large as there is a property per data access object. Also, with each new DB table that we model, we have to also update the abstract factory which really breaks the open closed principle.