Каковы плюсы / минусы возврата объектов POCO из репозитория в большей степени, чем сущности EF?

Question

Следуя тому, как это делает Роб, у меня есть классы, сгенерированные мастером Linq to SQL, а затем копия этих классов, которые являются POCO. В своих репозиториях я возвращаю эти POCO, а не модели Linq to SQL:

return from c in DataContext.Customer
       where c.ID == id
       select new MyPocoModels.Customer { ID = c.ID, Name = c.Name }

Я понимаю, что преимущество этого в том, что модели POCO могут быть проще созданы, так что это сделает мой код более тестируемым.

Сейчас я перехожу от Linq к SQL к Entity Framework, и я на полпути к книге EF. Кажется, я могу потерять много добра, возвращая POCO из моих репозиториев, а не из сущностей EF.

Я до сих пор не принимал модульное тестирование, поэтому мне кажется, что я трачу много времени на создание этих дополнительных POCO и написание кода для их заполнения, когда все, что мне кажется, это тестируемый код, но я Я также потеряю многие преимущества EF, не имея возможности отслеживать мои объекты.

У кого-нибудь есть совет относительно относительного новичка ко всему этому ORM / репозиторию?

Anthony

Answer 1

Другая причина, по которой людям не нравятся автоматически сгенерированные объекты (например, в LINQ to SQL), заключается в их встроенной «магии».

Обычно магия невидима, и вы ее никогда не замечаете, но когда вы пытаетесь сделать что-то вроде сериализации одного из этих объектов, а затем десериализовать его (например, при использовании веб-сервисов), его внутреннее соединение с источником данных нарушается и становится особенным Нужно использовать хаки, чтобы «вернуть магию обратно».

С POCO вам не нужно беспокоиться о подобных вещах, и вы сможете лучше разделить уровни данных и сервисов. Недостатком, конечно же, является то, что вам нужно написать много скучного кода преобразования POCO -> магический объект -> POCO. Но в конце я думаю, что это обычно того стоит, особенно для больших или сложных проектов.

Answer 2

Основная причина в том, что многим людям нравится разрабатывать свои модели с особым мышлением: например, DDD. Они могут захотеть использовать определенный шаблон (например, Spec или State) для таких вещей, как состояния (вместо перечислений), или вы можете использовать Factory для создания экземпляров.

OO ломается, когда вы пытаетесь использовать Таблицы как Объекты, когда вещи становятся более сложными. Простые сайты работают хорошо, но когда вы добираетесь до больших вещей, они становятся ужасными.

Так что - как всегда - это зависит от того, во что вы думаете, превратится ваш проект.

Answer 3

Мой опыт показывает, что когда вы начинаете писать сложные запросы. Метод Include бесполезен, и вы окажетесь либо:

а) Написание большого количества запросов для получения нужных вам данных или б) злоупотребление анонимными типами для загрузки данных в одном запросе, а затем написание большого количества кода просто для передачи этих данных вашим сущностям.

POCO - это путь, ИМХО.