Параметры интерфейса между веб-службой WCF / REST, Entity Framework и интерфейсом WebForms: каковы мои варианты?

Question

Я только что вышел из небольшого проекта с использованием веб-службы WCF / REST, которая использовала Entity Framework для доступа к базе данных, применила некоторую незначительную бизнес-логику и передала результаты в интерфейс .NET Webforms. Это сработало довольно хорошо, но первоначальный проект был составлен без большого количества времени для изучения вариантов, и теперь меня просят сделать еще один очень похожий проект. У меня есть немного больше времени, чтобы посмотреть, что там, и, возможно, сделать этот проект лучше, чем первый.

Я хочу выяснить, существуют ли более эффективные способы решения нескольких задач, в частности, передачи объектов назад и вперед между веб-службой и внешним интерфейсом.

Для первого проекта я создал общую библиотеку с определениями классов, которые использовались и веб-службой, и веб-сайтом. Когда в веб-службу поступил запрос, были выполнены запросы к БД, была применена бизнес-логика, а объект одного из общих типов был создан и передан обратно в ответ веб-службы.

Когда веб-сайт получил ответ, он десериализовал его в соответствующий общий объект и продолжил свой веселый путь.

Работало нормально, но нужно было написать много кода, чтобы определить общий объект, а затем отобразить результаты запроса / результаты бизнес-логики на общий объект.

Есть ли лучший способ? В частности, я ищу способ:

• автоматически генерирует объекты. (Я не уверен, что есть - похоже, я мог бы автоматически генерировать объекты, которые были специально сопоставлены с объектами базы данных, такими как таблицы или представления (и действительно, это то, что делает Entity Framework), но как насчет объектов, которые должны включать информацию не из БД что-то вроде бизнес-логики?)

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

Answer 1

Я работаю над аналогичным проектом, и вот что я делаю (вы можете решить, работает ли он для вас или нет).

• Вид использует UIModel
• Когда вызывается функция, я передаю свою UIModel в ServiceManager, который отображает UIModel в ServiceModel
• ServiceManager отправляет ServiceModel в службу (я использую RestSharp для сокращения кода отображения)
• Мой сервис получает ServiceModel и немедленно сопоставляет его с BusinessModel (я использую ServiceStack, чтобы снова сократить код сопоставления)
  • Единственная задача службы - развернуть объект службы и соответствующим образом направить его. Это скрывает внутренние детали моего фактического бизнес-уровня. Если это не важно для вас, тогда ваша BusinessModel может быть такой же, как ваша ServiceModel (и, возможно, такая же, как ваша модель базы данных)
• Мой сервис отправляет бизнес-модель в BusinessManager, который выполняет любую бизнес-логику, а затем создает модель PersistenceModel для передачи в RepositoryManager для сохранения
• Тогда весь процесс переворачивается

Итак, я получаю 4 модели, которые приведены ниже:

• Пользовательский интерфейс имеет собственную модель
• ServiceManager и Service совместно используют модель (которая также является целью ServiceManager; отделить заботу об интерфейсе пользователя от службы)
• Бизнес-логика имеет собственную модель
• Логика персистентности имеет собственную модель

Это, как уже упоминалось выше, позволяет разделить проблемы. Я могу потенциально изменить свою модель постоянства без необходимости изменять мои контракты, установленные в службе (которая будет общедоступной). Это сделает так, чтобы внутренние изменения не ломали внешние приложения. Однако вы рискуете изменить все модели.

Что касается основы их сопоставления, я использую AutoMapper. Таким образом, код не загроможден отображениями из-за AutoMapper, RestSharp и ServiceStack. Код выглядит как код:)

Я не уверен, что это полностью отвечает на ваш вопрос, но это похоже на то, что вы объясняете.

UPDATE:

Это попытка взять вышеизложенное и сделать его еще более специфичным для решения BDW ASP.NET:

• Создайте отдельный проект, в котором будут храниться только ваши UIModels.
• Ссылка на это в вашем проекте asp.net, и ожидайте использовать это для любой логики asp.net
• Создайте отдельный проект, в котором будут храниться только ваши ServiceModels.
• Когда вам нужно позвонить в Службу, преобразуйте данные из вашей UIModel в вашу ServiceModel
  • Это можно сделать внутри вашего проекта asp.net. Или вы можете создать новый проект, который будет принимать модель пользовательского интерфейса и выполнять преобразование и вызов службы для вас (таким образом, на вашу сервисную модель не нужно ссылаться в части asp.net)
• Создайте другой проект, который будет вызывать службу для вас, используя ServiceModel
• Теперь вы к вашим услугам и, согласно вашему комментарию, вы можете справиться с остальными