ASP.NET MVC and ADO.NET Entity Framework

Question

I have a problem that I cannot solve without some advice. I'm developing an ASP.NET MVC application and I'm using ADO.NET EF to connect to the database. My problem is that I don't know if business logic of my app should use entities created by EF or should I create one more abstraction layer and separate EF entities from my business logic objects (and develop some converters between those object types). Or maybe I'm totally wrong and I should do it differently? How? Which solution would be best practice?

Answer 1

This absolutely depends on your application, its scope and its requirements. Introducing abstraction layers just for layers' sake means introducing complexity and indirection, where often it doesn't really get you anywhere. For the overuse of layered architecture the term Lasagna Software is currently being introduced - replacing the infamous Spaghetti Software.

To make this clear, I'm not proposing against abstraction layers. Using them just highly depends on your specific requirements.

I'd start with a simple architecture and add layers as required to ensure testability and maintainability. The current version Entity Framework (4.1 as of this writing) allows working with POCOs and the DbContext pretty much resembles the Repository and Unit of Work patterns. These out-of-the-box features might be sufficient for a start in most cases.

Answer 2

I have handled situations like this by having separate projects for the Data classes and the Model classes.

The Data classes would be the ones generated by your ADO.net model, then you can use the Repository pattern to connect to the ADO.net context, retrieve the data classes, and use something like http://automapper.codeplex.com/ to map the data class to the business model.

This will allow you to use the MVC validation such as Required, Regex, etc on the models, and keep away from messing with the Data classes, and only pass around the Models.

Answer 3

In general, I find it best to place business logic both in the domain model, and in a service layer. Logic in the domain model is preferable, as it is easier to test, but not all logic is easily implemented in this way. E.g. when an operation involves many domain objects, you cannot always reasonably place it within one of them without performance implications and other issues.

Answer 4

This is where POCO's come into play. You can generate generic POCO's from your data model and use them in your business layer. EF will then create POCO's and track them.

The idea here is that your POCO's are just entities, and not EF objects (though EF does, behind the scenes create proxied versions of your POCO's)