Перемещение сервисного слоя в стиле MVC в WCF

Недавно я работал с MVC4 и вполне освоился со стеком View> View Model> Controller> Service> Repository с IoC и всем остальным. Мне это нравится. Это работает хорошо. Тем не менее, мы движемся к общекорпоративной платформе приложений, которая будет обслуживать большинство бизнес-приложений внутри компании.

Основные цели архитектуры:

  • Клиент, обращенный к сайту MVC
  • Веб-сайт внутреннего администратора
  • Множество запланированных заданий по импорту/экспорту данных/и т. д. третьим сторонам
  • Служебный автобус, расположенный посередине, для демонстрации деловых мероприятий
  • Общедоступный API для использования клиентами

Мои первоначальные мысли заключаются в том, чтобы ввести «уровень корпоративных служб», применяя мои интерфейсы служб к контрактам WCF и регистрируя прокси-классы WCF в моем IoC. Это позволило бы мне повторно использовать тот же шаблон, который я использую в настоящее время, но я не нашел много примеров этого на практике. За исключением этот парень.

Правда, я не уверен, какое решение лучше всего подходит для проекта такого масштаба.

1) Что следует учитывать при централизации бизнес-служб?

2) Как это повлияет на сквозные проблемы, такие как проверка, авторизация и т. д.? Я думал, что уже понял это, но размещение DTO между слоями все меняет.

3) У меня есть опыт работы с WCF, но я слышал, что Service Stack сейчас в моде... Должен ли SS быть соображение с его RESTful совершенством?


model-view-controller wcf service-layer business-logic-layer
person Jeremy Smith    schedule 23.05.2013    source источник

Ответы (2)


arrow_upward
1
arrow_downward

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

Основная проблема с использованием IoC для разрешения зависимостей WCF ChanelFactory согласно моему сообщению заключается в том, что клиенту также необходимо иметь доступ к контрактам службы. Это нормально для архитектуры вида View > View Model > Controller > Service > Repository, но вряд ли возможно (или нежелательно) для общедоступного API.

В попытке охватить ваши другие вопросы:

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

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

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

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

ReST, безусловно, сейчас популярен. Я не использовал сервисный стек, но получил хорошие результаты с Asp.Net Web Api. Кроме того, WCF также может выполнять РЕСТ.

person jheppinstall    schedule 23.05.2013
comment
RE: общедоступный API, я на самом деле планирую сохранить бизнес-сервисы внутри и предоставить клиентам отдельный упрощенный API, вероятно, через REST, который будет использовать наши бизнес-сервисы внутри компании. Это устранило бы их зависимость от моих сервисных контрактов, позволило бы лучше контролировать то, к чему у них есть доступ, и позволило бы лучше контролировать модель безопасности в демилитаризованной зоне. - person Jeremy Smith; 23.05.2013

arrow_upward
0
arrow_downward

Ранее я подробно объяснял технические и философские различия между ServiceStack и WCF на InfoQ. С точки зрения дизайна API этот более ранний ответ показывает различия между подходом на основе сообщений ServiceStack и WCF. / Подход к удаленному методу WebApi.

Поддержка SOAP

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

HTML, Razor, Markdown и MVC

В ServiceStack также есть отличная история HTML, которая может работать автономно с поддержкой Razor в качестве можно увидеть в razor.servicestack.net или Markdown Razor, как показано в servicestack .net/docs/.

ServiceStack также хорошо интегрируется с ASP.NET MVC, как показано в Social Bootstrap API, который также может использовать преимущества качественных альтернативных компонентов ServiceStack.

person mythz    schedule 23.05.2013
comment
Сквозные проблемы — это то, о чем я зациклился на ServiceStack. Хотя я новичок в SS, я не нашел хороших примеров того, как проверка может быть возвращена в различные типы приложений (веб-приложения MVC, консольные приложения и т. д.) без помещения моих DTO в какой-либо транспортный контейнер, содержащий детали проверки (что может раздуть мои ответы). Не могли бы вы пролить свет на эту тему? Кроме того, я вижу, что есть поддержка транзакций через Redis (?), но у меня нет с этим опыта (например, проходит ли он весь путь до базы данных?). Я использовал только WCF + MSMQ + DTC - person Jeremy Smith; 23.05.2013
comment
Вся информация об исключении сериализуется в свойстве ResponseStatus в DTO, включая отдельные ошибки поля проверки. Если ошибок нет, ResponseStatus пуст. Вы можете получить доступ к этой информации об ошибке в представлениях Razor с помощью свойств base.ResponseStatus и @ModelError. На самом деле мы рассматриваем «сквозные» проблемы, связанные с тем, что одна и та же служба также может служить моделями представлений в HTML-представлениях как функция, поэтому одна и та же служба может использоваться веб-клиентами или мобильными клиентами и т. д. Задайте другие несвязанные вопросы в новом вопросе. - person mythz; 23.05.2013