Проблемы приложения WCF и Entity Framework уровня приложений - PullRequest
Новая
       55

Проблемы приложения WCF и Entity Framework уровня приложений

0 голосов
/ 12 марта 2012

Я занимаюсь разработкой службы WCF, которая является частью более крупной системы.Сервис предоставит некоторую бизнес-логику и будет подключен к базе данных через Entity Framework (используя модель-сначала).Я вижу, что есть много разных способов работы с Entity Framework с WCF-сервисом (базовые объекты, DTO, объекты самоконтроля, POCO и т. Д.).Мои основные требования:

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

Из-за моих требований мое видение того, как его следует строить,ближе всего к (я думаю, что это самый близкий к подходу DTO): http://www.codeproject.com/Articles/127395/Implementing-a-WCF-Service-with-Entity-Framework

Но я думаю, что уровень доступа к данным должен быть отделен от логики Сервиса (2 сборки: проекты, пространства имен, библиотеки DLL,но работает как одно приложение).В этом случае у меня есть некоторые проблемы, что должен делать каждый из этих двух уровней: должна ли вся логика выполняться в сервисе, и DAL будет использоваться просто как CRUD?Или Service должен отвечать только за четкую бизнес-логику, тогда как вся логика базы данных (конкретные запросы, использующие linq) будут выполняться в DAL (многие более специфические методы предоставляются DAL)?Также, что важно, какие объекты должны быть отправлены между этими двумя уровнями: контракты данных, сущности или дополнительная модель?

Мой подход в указанной ситуации в порядке?

1 Ответ

1 голос
/ 12 марта 2012

До SOA, N- или 3-уровневые архитектуры обычно имели выделенный бизнес-уровень.Если вы чувствуете себя достаточно твердо в отношении разделения интересов (или если вы думаете, что вы можете получить некоторое повторное использование своих бизнес-функций от не-сервисных потребителей), почему бы не вывести свою бизнес-логику из уровня обслуживания?(но не помещайте бизнес-логику в свой DAL)

Однако, если ваш сервисный уровень предлагает сервисы запросов данных, а также транзакционные, тогда бизнес-уровень не нужен для этих сервисов - посмотритев шаблонах проектирования типов CQRS здесь.

Если вам нужно контролировать формат XML ваших сущностей (Names, xmlns и т. д.), вам, вероятно, понадобится создавать собственные сущности WCF DataContract или MessageContract.Однако, если вам все равно, как выглядят данные по сети, вы можете просто использовать классы EF Entity (если они не привязаны к контексту, то есть если использовать POCO с EF).Если вы не приписываете POCO с помощью DataContract и т. Д., Поведение DataContractSerializer по умолчанию заключается в сериализации открытых свойств.

Таким образом, вы можете получить следующие «слои» сборки (снизу вверх)

  • Объекты DAL для EF (привязаны к ObjectContext или POCO)
  • EF DAL
  • Бизнес-уровень (только для методов транзакционного обслуживания - обойдено для запросов)
  • Возможно разделитьОбъекты WCF, где вы сопоставляете свои POCO / DAL BE с DataContract / MessageContract
  • Сервисный уровень WCF
...