Having POCOs, Entities and ViewModels in a solution feels like overkill

Question

The latest version of the Entity Framework got me in love, still at good as it is I don't like using entities objects as domain objects for all the obvious headaches, so what I'm doing is translating retrieved entity objects in my services and returning POCOs to whomever consumes the service. Thanks to automapper the translation from pocos to entities and back results in some easily maintainable code inside the services. Where things get hairy is when you add ViewModels to the picture and you end up mapping a viewmodel to the poco in the controller and then mapping the poco to the entity object in the service to be stored in the repository.

Would you consider this an overkill or am I being too nitpicking ?

Answer 1

It's not 'overkill' but 'overhead'. And It is inevitable when you want proper layering. The ViewModels belong to the UI layer, you don't want to mix that with the POCOs.

And while you might call it 'overkill' for a small app, which boundary would you rather sacrifice?

Answer 2

Entity Framework 4 has built-in support for POCO's. A good place to start on that is http://blogs.msdn.com/b/adonet/archive/2009/05/21/poco-in-the-entity-framework-part-1-the-experience.aspx

In short, you can have your domain model project that is completely persistence ignorant. You can use this approach with the newly introduced Code First approach in EF 4. Now you don't need Automapper anymore for your POCO's to Entity Objects conversion and vice versa. You can, however, use Automapper to map between POCO's and ViewModels reducing a lot of the plumbing code.

HTH.

Answer 3

Just want to say that as far as I can tell Rails, Django, and most PHP MVC frameworks don't favor the POCO approach.

Are they all "doing it wrong"?

POCOs in C#/MVC sometimes feel like ceremony code to me. The worse part is if your POCO changes your view model has to as well. Doesn't that validate DRY?