Наличие POCO, Entities и ViewModel в решении кажется излишним

Question

Последняя версия Entity Framework заставила меня полюбить, но все еще в хорошем состоянии. Я не люблю использовать объекты-сущности в качестве объектов домена для всех очевидных головных болей, поэтому я занимаюсь переводом извлеченных объектов-сущностей вмои услуги и возвращение POCO тому, кто их использует.Благодаря autopper перевод из pocos в сущности и обратно приводит к некоторому легко поддерживаемому коду внутри сервисов.Когда дело доходит до волосатости, это когда вы добавляете ViewModels к изображению, и в итоге вы отображаете модель представления в poco в контроллере, а затем отображаете poco в объекте сущности в сервисе, который будет сохранен в хранилище.Ты считаешь это излишним или я слишком придирчив?

Answer 1

Entity Framework 4 имеет встроенную поддержку POCO.Хорошее место для начала это http://blogs.msdn.com/b/adonet/archive/2009/05/21/poco-in-the-entity-framework-part-1-the-experience.aspx

Короче говоря, у вас может быть проект модели вашего домена, который полностью игнорирует постоянство.Вы можете использовать этот подход с недавно представленным подходом Code First в EF 4. Теперь вам больше не нужен Automapper для преобразования ваших объектов POCO в Entity Objects и наоборот.Тем не менее, вы можете использовать Automapper для отображения между POCO и ViewModels, уменьшая большую часть кода.

HTH.

Answer 2

Это не «перебор», а «накладные расходы».И это неизбежно, когда вы хотите правильное наслоение.ViewModels относятся к слою пользовательского интерфейса, вы не хотите смешивать это с POCO.

И хотя вы можете назвать это «избыточным» для небольшого приложения, какую границу вы бы предпочли пожертвовать?