Когда следует использовать POCO в EF4? - PullRequest
Новая
       13

Когда следует использовать POCO в EF4?

9 голосов
/ 22 июня 2010

У нас есть веб-сайт ASP.Net MVC2, и мы используем EF4 для доступа к базе данных и т. Д. Будучи новичком в EF4, мы столкнулись с концепцией POCO EF4, однако не полностью ее понимаем.

В общем, я слышал, что POCO определяется как объекты, "не зависящие от внешней структуры". Я предполагаю, что в случае EF4 это означает, что POCO подразумевает создание более легких объектов? Если дело обстоит именно так, что у EF4 сантехники нет у POCO, каковы плюсы / минусы этого, какая дополнительная работа по разработке может понадобиться с POCO. Таким образом, когда лучше использовать POCO в EF4?

Ответы [ 2 ]

14 голосов
/ 22 июня 2010

«POCO» - неопределенный термин в пространстве ORM. Люди по-разному используют это для обозначения:

  • «Чистые» POCO, которые не отслеживают изменения, не загружаются, имеют личные свойства и т. Д. С ними может быть сложно работать.
  • Psuedo-POCO прокси: типы со всем public virtual и имеющие разные типы во время выполнения.
  • Самостоятельно отслеживаемые объекты. Не POCO, но и не EntityObject.

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

Что не так с EntityObject? Не много. Он довольно легкий и является частью .NET. Даже в профиле клиента .NET 4. Это даже не цепляет вас к EF. Хотя было бы странно использовать его как «тип POCO» с другой структурой, он работал бы просто отлично. Тем не менее, это не в Silverlight, IIRC.

С объектами POCO сложнее работать, потому что вы теряете материал, который EntityObject дает вам бесплатно. Это не много, но нужно подумать, прежде чем выбирать POCO, просто потому что «они крутые», особенно для новичков в EF.

Одна вещь, которую многие люди, проявляющие религиозность в отношении POCO, склонны игнорировать: отображение типов, не относящихся к POCO, никоим образом не ограничивает возможность подвергать эти типы, не относящиеся к POCO, извне. Ваши службы данных могут проецировать сопоставленные типы, отличные от POCO, на не сопоставленные DTO POCO, и вы можете выбрать показ только этих типов, т.е. 

public IEnumerable<FooDto> IFooRepository.SelectAll()
{
    return from f in Context.Foos
           select new FooDto { Id = f.Id, Name = f.Name };
}

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

Когда вам абсолютно необходимы типы не EntityObject для отображения? Что ж, если вам нужны самообследуемые объекты, это открытый и закрытый случай. Если вам необходимо предоставить доступ к отображаемым типам для Silverlight, то это тоже ясно.

Кроме того, это менее ясно. Если вы пишете службу данных для общественного пользования, то не следует делать DTO подтипами EntityObject, потому что это помешает подключить другую среду позже. Я бы никогда не сделал неизменный общедоступный интерфейс зависимым от какой-либо одной среды, даже той, которая включена в .NET. С другой стороны, как я уже говорил выше, вы можете выставлять один тип и отображать другой; никогда не требуется выставлять сопоставленные типы, и зачастую это очень веские причины не предоставлять их (возможно, они содержат непубличные данные).

9 голосов
/ 08 августа 2010

Я полностью согласен с Крейгом, с POCO сложнее работать.

Я добавлю больше о цели POCO, я надеюсь, вы поймете, когда следует использовать, а когда не использовать.

Модель и обслуживание: ОСНОВНЫЕ

Модель и сервис - это одна из самых важных частей вашего приложения, изменение НЕТ-НЕТ-НЕТ, вы не можете избежать тесной связи модели и сервиса с какой-либо частью вашего приложения, таким образом, небольшое изменение модели требуют изменения всего приложения.

Речь идет о гибкости

POCO зависит от языка, а не от фреймворка. это простой класс, который не имеет зависимости от класса, специфичного для фреймворка, вы можете использовать POCO во всех версиях .net, включая микро фреймворк и компактный фреймворк.

Речь идет о тестировании

POCO действительно прост для модульного тестирования, потому что он не зависит от класса, не дружественного для юнит-тестирования.

Речь идет об изменениях

Обновление / Понижение, создание нового клиентского приложения в другой среде, такой как MONO? проблем не возникнет, вы можете продолжать использовать свой сервис и модель, даже если худший уровень обновления / понижения будет иметь место только в View and Service Cotext Helper.

Речь идет о естественном

Создание и работа с POCO проста и естественна, вы можете четко написать свой бизнес-процесс.

Но помните, что POCO не дружит с каркасом

Я согласен с Крейгом, POCO - это TOO COOL , Too Cool, чтобы подружиться с новыми людьми. Посмотрите на WPF, это требует модель, которая реализует INotifyPropertyChanged, что вы делаете для этого? Вы можете сделать обертку или вы можете сделать динамический прокси вашей модели. но это требует более продвинутой техники и кода для поддержки.

...