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?

1 Answer 1


Disclaimer: I don't use entity framework and am heavily biased against just about any database helper framework.

It looks like you have made a wrapper.

I make a distinction between "wrapper" and "layer". Layer being something you might compile to it's own DLL/project/Jar/whatever. The data access layer. Wrapper being a "helper" class you use within that DLL. With the purpose of simplifying the interface, or maybe eliminate duplication.

The problem with simplifying the interface of database access is it's commonly not simple. You either end up duplicating the interface of ADO/JDBC/etc. Or you force people to bypass it. Wrappers tend to do all sorts of unwanted things. They may automatically close a connection when you need it open to support a transaction. They often mistakenly leave connections open if you had to stream data, and are using one of those garbage collected languages. To give the full power of the library behind your wrapper you are forced to duplicate it.

Libraries like ADO/JDBC are already a GREAT interface. They are some of the finest examples of OOP done right. I would prefer to use them over a wrapper some wizbang pulled out of his hat.

The classic JDBC/ADO style interface is well known and understood. The wrapper you pulled out of your hat is not.

Want to reduce redundant "paramters.Add"? Look into generics. Or just accept that by trying to reduce "paramter.Add" you actually just push the ".add" to another layer of code.

BTW this is a great question. I'd upvote it 10 times if I could.

Edit: Of course JDBC code would be hidden away in the data access layer.

  • I agree, in hindsight, that this is more a wrapper around EF 4 than itself. The idea behind it was to allow different pieces of database connectivity (such as a standard data model) to be re-used whilst also having a single point of entry for multiple databases, each with the re-usability characteristic. This database wrapper is compiled in to a separate library (along with other business logic). How would you suggest I change my design to improve it?
    – Andy Hunt
    Dec 28, 2011 at 13:00
  • +1 for the great content despite your EF Bias... though EF is more than a DB helper framework. You are right about his trying to make a wrapper for this. Dec 28, 2011 at 16:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.