Когда должен ПОСТЕПЕННО использоваться в EF4?
Мы имеем веб-сайт ASP.Net MVC2 и используем EF4 для доступа к базе данных и т.д. Будучи плохо знакомыми с EF4, мы столкнулись с EF4 ПОСТЕПЕННО понятие, однако не полностью понимайте это.
В целом я услышал ПОСТЕПЕННО определенный как объекты, "не зависящие от внешней платформы". В случае EF4 я предполагаю, что это означает, что ПОСТЕПЕННО подразумевал бы так или иначе создающие объекты более легкого веса? Если это верно, что ПОСТЕПЕННО не имеет инфраструктура EF4, что является профессионалами/недостатками этого, с чем дополнительная техническая разработка могла бы одна потребность ПОСТЕПЕННО. Таким образом, когда хорошо использовать ПОСТЕПЕННО в EF4?
2 ответа
«POCO» - расплывчатый термин в пространстве ORM. Люди по-разному используют его для обозначения:
- «Чистых» POCO, которые не отслеживают изменения, не загружают файлы, имеют частные свойства и т. Д. С ними может быть сложно работать.
- Psuedo-POCO прокси: типы со всем
общедоступным виртуальными которые имеют разные типы во время выполнения. - Самостоятельно отслеживающие сущности. Не POCO, но и не
EntityObject.
Я считаю, что определение «не зависящее от внешней структуры» несколько корыстно. Это способ игнорировать ограничения фреймворка. То есть в моей книге прокси-серверы не являются настоящими POCO, но они соответствуют этому определению.
Что не так с EntityObject ? Не много. Он довольно легкий и является частью .NET. Это даже в клиентском профиле .NET 4. Он даже не привязывает вас к EF. Хотя было бы немного странно использовать его как «тип POCO» с другой структурой, он работал бы нормально.Но это не в Silverlight, IIRC.
С объектами POCO труднее работать, потому что вы теряете то, что EntityObject дает вам бесплатно. Это не так уж и много, но о чем следует подумать, прежде чем выбирать POCO только потому, что они «классные», особенно для новичков в EF.
Одна вещь, которую многие люди, которые религиозно относятся к POCO, склонны игнорировать: сопоставление типов, не относящихся к POCO, никоим образом не ограничивает вас открывать эти типы, не относящиеся к POCO, извне. Ваши службы данных могут проецировать сопоставленные типы, отличные от POCO, на несопоставленные POCO DTO, и вы можете выбрать раскрытие только этих типов, например :
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. С другой стороны, как я сказал выше, вы можете раскрыть один тип и сопоставить другой; нет необходимости раскрывать сопоставленные типы, когда-либо, и часто есть очень веские причины не раскрывать их (возможно, они содержат закрытые данные).
Я полностью согласен с Крейгом, с POCO труднее работать.
Я добавлю больше о цели POCO, надеюсь, вы поймете, когда следует его использовать, а когда нет.
Модель и сервис - это CORE
Модель и сервис - одна из самых важных частей вашего приложения, это НЕТ-НЕТ-НЕТ изменять, вы не можете избежать тесной связи модели и сервиса с какой-либо частью ваше приложение, поэтому небольшое изменение модели потребует изменения всего приложения.
Речь идет о гибкости
POCO зависит от языка, а не от фреймворка. это простой класс, не зависящий от конкретного класса фреймворка, вы можете использовать POCO во всех версиях .net, включая микро-фреймворк и компактный фреймворк.
Речь идет о тестировании.
POCO действительно легко поддается модульному тестированию, потому что он не зависит от класса, не дружественного к модульному тестированию.
Речь идет об изменениях
Обновление / понижение версии, создание нового клиентского приложения в другой среде, например, в MONO? не будет проблем, вы можете продолжать использовать свой сервис и модель, даже если наихудшее обновление / понижение будет происходить только в View и Service Cotext Helper.
Речь идет о естественности.
Создание и работа с POCO проста и естественна, вы можете четко написать свой бизнес-процесс.
Но помните, что POCO не дружит с фреймворком
Я согласен с Крейгом, POCO СЛИШКОМ КЛАССА , Слишком круто, чтобы заводить дружбу с новыми людьми. посмотрите на WPF, требуется модель, реализующая INotifyPropertyChanged, что вы делаете для этого? вы можете создать оболочку или сделать динамический прокси для своей модели.но для этого требуется более продвинутая техника и код.