Entity Framework в многоуровневой архитектуре?

Question

Проведение некоторых экспериментов вокруг WCF и Entity Framework. Пара вопросов.

Вариант 1:

Я понимаю, что классы структуры сущностей можно сериализовать напрямую через WCF, начиная с sp1. Как бы то ни было, я хотел бы знать, как в этом обрабатываются такие сценарии, как отложенная загрузка, активная загрузка, управление контекстом и т. Д., Если они вообще обрабатываются?

Вариант 2:

Другой альтернативой может быть использование EFPocoAdapter, чтобы иметь простую оболочку POCO поверх структуры сущностей, вместо непосредственного предоставления классов структуры сущностей. http://code.msdn.microsoft.com/EFPocoAdapter. Кто-нибудь использовал это? Есть мысли в этом направлении?

Другие мысли:

О службах данных ADO.NET. Как я понимаю, службы данных ADO.NET не могут быть настроены через удаленное взаимодействие (связывание nettcp)? Он поддерживает только доступ на основе http. Мы все знаем, что двоичная сериализация медленнее.

Любые указатели или другие варианты?

Answer 1

Я немного покопался в этом, и вот мои выводы по этому вопросу.

Службы данных ADO.NET:

Вы можете использовать службы данных ADO.NET (вам необходим пакет обновления 1) для предоставления вашей структуры Entity по проводам с практически нулевым кодом. Но, как я понимаю, единственным ограничением является транзакция через HTTP. Это означает, что с точки зрения сериализации есть небольшие накладные расходы (мы все знаем, что двоичная сериализация быстрее), но преимущество заключается в скорости реализации наших сервисов.

Я получил неофициальное слово от Джона [http://twitter.com/John_Papa] об этом - «Определенно больше возможностей с wcf. Больше работы в большинстве случаев тоже. Astoria легко раскрывает сущности. Perf diffs в большинстве случаев незначительны» *

Преимущества - вам вообще не нужно писать никаких сервисов - вы можете просто подключить логику валидации и безопасности к сервисам данных и структуре сущностей, и все готово. Идеально, если вы используете сервисы, ориентированные на данные, по протоколу http - в таких случаях, как использование клиента Silverlight или интерфейса winform / wpf через http.

Предоставление Entity Framework через WCF:

В пакете обновления 1 (SP1) существует широкая поддержка использования структуры сущностей в многоуровневых архитектурах. Это включает в себя поддержку быстрой загрузки и управления контекстом. Конечно, в этом случае нам нужно написать сервисы (и логику наших методов). Или, если у нас есть модель структуры сущностей, полностью совмещенная с базой данных, мы могли бы генерировать большинство сервисов, которые включают необходимые нам методы.

Рекомендую вам прочитать это http://msdn.microsoft.com/en-us/magazine/cc700340.aspx

Другой альтернативой может быть использование EFPocoAdapter, чтобы иметь простую оболочку POCO поверх структуры сущностей для dtos, вместо непосредственного предоставления классов структуры сущностей. Сейчас это компасный проект для следующей версии Entity Framework http://code.msdn.microsoft.com/EFPocoAdapter.

Answer 2

Очень плохая идея выставлять классы EF поверх WCF. Microsoft допустила несколько серьезных ошибок, которые мешают этому быть полезным сценарием. Они представили сущности как данные, а также базовые классы сущности, а для обратных ссылок выставляют две копии ссылки.

С другой стороны, кажется, что ADO.NET Data Services обладают некоторой магией, которая позволяет чему-то близкому к этому работать. Прочитайте статью SilverLight в журнале MSDN за этот месяц, чтобы узнать пример использования ADO.NET Data Services со стороны клиента.

Answer 3

Не поднимать старую запись, но ... Я нашел этот список, когда имел дело с точно такой же проблемой. У нас есть сервисы WCF и модель предметной области Entity Framwork. В конце концов я сделал T4 на основе работы Дэнни Симмонса, которая берет EDMX и создает классы сообщений POCO вместе с методами расширения, которые отображают entity.ToMessage () и message.ToEntity (objectcontext).

Это казалось лучшим промежуточным подходом до .NET 4.0, так как он не требует никаких дополнительных внешних зависимостей проекта или скачков, чтобы перепрыгивать, как другие методы, которые я нашел (основанные на PostSharp).

Если кто-то еще посчитает этот подход полезным, дайте мне знать, и я опубликую ссылку на файл TT на нашем сайте googlecode.