Entity Framework POCO Сериализация

Question

Я скоро начну кодировать новое веб-приложение. Приложение будет построено с использованием ASP.Net MVC 3 и Entity Framework 4.1 (подход Database First). Вместо использования классов EntityObject по умолчанию я создам классы POCO с помощью ADO.NET POCO Entity Generator.

Когда я создаю POCOs с помощью этого инструмента, он автоматически добавляет ключевое слово Virtual ко всем свойствам для отслеживания изменений и свойств навигации для ленивой загрузки.

Я, однако, читал и видел из демонстраций, что Джулия Лерман (EF Guru!), Кажется, отключает ленивую загрузку, а также изменяет свой шаблон POCO, чтобы ключевое слово Virtual было удалено из ее классов POCO. Джулия заявляет, почему она это делает, потому что она пишет приложения для служб WCF и использует ключевое слово Virtual, что вызывает проблему с сериализацией. Она говорит, что когда объект сериализуется, сериализатор касается свойств навигации, которые затем запускают ленивую загрузку, и, прежде чем вы это узнаете, вы тянете всю базу данных по проводу.

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

Мой вопрос (наконец), следует также удалить ключевое слово Virtual из моих классов POCO для моего приложения MVC и использовать DectectChanges для отслеживания изменений и Eager Loading для запроса свойств навигации.

Ваша помощь в этом была бы принята с благодарностью.

Спасибо, как всегда.

Answer 1

Сериализация действительно может инициировать ленивую загрузку, поскольку получатель свойства навигации не имеет способа определить, является ли вызывающий код сериализатором или кодом пользователя.

Это не единственная проблема: есть ли у вас свойства виртуальной навигации или все свойства, так как виртуальный EF будет создавать прокси-тип во время выполнения для ваших сущностей, поэтому экземпляры сущностей, с которыми сериализатор будет иметь дело во время выполнения, обычно будут иметь тип, отличный от того, который вы определили.

Рекомендации Джули являются самым простым и разумным способом решения проблем, но если вы все еще хотите работать с возможностями прокси-серверов большую часть времени и только иногда сериализуете их с помощью WCF, есть и другие обходные пути:

• вы можете использовать DataContractResolver для отображения типов прокси сериализовать как оригинальные типы
• вы также можете отключить отложенную загрузку только тогда, когда вы собираетесь сериализовать граф

Mor Детали содержатся в этом блоге: http://blogs.msdn.com/b/adonet/archive/2010/01/05/poco-proxies-part-2-serializing-poco-proxies.aspx

Кроме того, моя рекомендация заключалась в том, что вы используете шаблон DbContext, а не шаблон POCO. DbContext - это новый API, который мы выпустили как часть EF 4.1 с целью обеспечения большей производительности.У этого есть несколько преимуществ, как тот факт, что он автоматически выполнит DetectChanges, так что вам вообще не понадобится заботиться о вызове метода самостоятельно. Также объекты POCO, которые мы создаем для DbContext, проще, чем те, которые мы создаем с помощью шаблонов POCO. Вы должны быть в состоянии найти много примеров MVC, используя DbContext.

Answer 2

Ну, это зависит от вашей потребности, если вы собираетесь сериализовать свои классы POCO, чем да, вы должны удалить их (например: при использовании служб WCF или в основном что-либо, что будет сериализовать весь ваш объект). Но если вы просто создаете веб-приложение, которое должно получить доступ к вашим классам, чем я оставил бы их в ваших классах, поскольку вы будете контролировать объекты, к которым вы будете обращаться в своих классах через свой код.