Entity Framework POCO Сериализация - PullRequest
Новая
       24

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

2 голосов
/ 12 января 2012

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

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

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

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

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

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

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

Ответы [ 2 ]

4 голосов
/ 12 января 2012

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

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

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

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

Более подробная информация содержится в этом сообщении в блоге: 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.

0 голосов
/ 12 января 2012

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

...