I wrote the following a while back, but I've come to review it recently, and now don't think it's good design.
The design is for a kind of modular database layer using Entity Framework 4. There is a single database object which loads (lazily) entity framework contexts from external libraries in a specified location, and instances of the loaded contexts are stored in a hash table against their name (EG "ContentMgmtContext").
All contact with the database in this system is through stored procedures. To make a call to the database, the query method signature looks like this:
List<TReturn> Query<TReturn>(string Context, string Procedure, TransactionScope Scope, List<ObjectParameter> QueryParameters)
This modularity is something I like. However, there is one significant drawback to this approach:
when using the database layer, the code using it has to have a reference to the library in which the context is stored, in order to access the types returned by the stored procedures through Entity Framework. In the model, the objects from the database layer are translated in to new objects that the view and controller use.
I think this is bad design, but how can I improve it? I've considered adding an empty interface like
IStoredProecedureObject to give every data type returned by a stored procedure a common base type, however this appears to be foiled by Entity Framework. Every time the
.edmx file is recompiled, the code is generated anew, and any additions removed. Is there any way to stop this happening?
How can I improve this design? What (else) is wrong with it? Or am I on the right track?