I would like to know arguments for/against this concept.

Technologies in use from the bottom up:

  • MSSQL 2012 DB (exclusively accessed via sprocs)
  • Entity Framework
  • WCF Web Service
  • ASP.NET Webforms

Someone on my team would like to use Entity Framework to map the sprocs to ComplexTypes, and then use those ComplexTypes as DTOs, eventually using them as a view model to display on the page. His argument is that it's the fastest/easiest way and we'll get noticeable/valued changes more quickly. Also, he does not like the idea of the numerous mappings that would be necessary to go from DB -> Entity -> DTO -> ViewModel.

Another consideration is, the majority of things from the DB are going one direction (db -> web), with only a few things actually needing to be changed on the UI and saved/persisted to the DB.

To scope this question, there are thousands of previously existing sprocs written against poorly designed database structure (think tables that are 276 columns wide and single rows actually contain multiple entities). The poor structure isn't about to change soon because there are over 200 legacy apps written on top of it.

2 Answers 2


Yukky database... well, given that exists then the first thing you need to do is only allow access to the DB via sprocs, effectively encapsulate the DB in its own API. Once you do this, it'll eventually be possible to replace/redesign it without any client knowing.

Sounds like you've already done this, so good so far.

Now, accessing that API can be done in any number of ways, and using EF to do this is a good RAD way of doing it, even if SQLClient will be faster - doesn't make too much difference all in all.

Mapping a sproc's results to a ComplexType is exactly what a ComplexType is designed for (don't try to use it as if it were an EF view of a DB). Its a temporary result type that does not map to the underlying table - its effectively a dynamically generated type that contains just the results from the sproc and has no relation to the actual DB structure.

However, the problem comes when you try to write these back to the DB - you have to tell EF that the data in the type maps onto a DB table (or it won't know what to do with it), and we are trying to remove the whole DB schema from the service code, accessing the DB through its sprocs only. If you have sprocs to write, then there's no reason you can't just unpick the individual elements of the type and pass them to the relevant sproc in the WCF service. In this case, you simply make it easier to code your service to client code as EF does the class creation for you. Of course, if you've already got such classes for the sproc then its not really going to help you much.

So I think its safe to say he's right, its a simple and worthwhile convenience mechanism that should work well for you - assuming you're not trying to subvert the sprocs, or have a similar mechanism in place. You might find issues with getting the definition of the types into all parts of your chain, depending on how it all gets compiled together, but that's a solveable problem. I would get him to knock up a PoC demonstrating how a new service would call a simple sproc and transfer the data to the client (no need to write the web code to go with it) and back again, and review that. I think you'll find that it does what you've already been doing in a way that means the compiler does a load of boring work for you.

As for reducing the need to go Entity->DTO->View... there's a lot of complexity in web MVC that was put there because Ruby on Rails did it that way, and everyone says MVC is a great way to split your code up. My personal view is that MVC inside the same layer is just over-engineering the problem (that might be good if you only have that layer talking to the DB, not if you already have a well designed 3-tier solution). If you already have a web service and DB layer accessed via sprocs then you've done it right already, no real need to replicate this architecture in the web server as well! So yes, I'd remove as much of the web view code to make it as simple as possible.

  • I appreciate the well considered response. Thank you. Dec 30, 2013 at 20:00
  • 1
    @AaronPalmer np. Its difficult to say without knowing more about your setup, which seems to be done right. I assumed he was trying to get the tooling to do some of the lifting for you, not fundamentally replace anything. Keep the tiers though - don't expose your DB directly to the client!
    – gbjbaanb
    Dec 31, 2013 at 14:07

Since your database is poorly designed, and you have a high legacy code base, ANY new project should employ as much abstraction as practical. You will eventually want to replace that ugly database design with proper normalization, and replicate the existing lousy structure with a compatibility model.

Entity Framework itself may not be useful, but at least one layer of abstraction is appropriate and, if you're professional, necessary.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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