Преместване на сервизен слой в стил 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 със сигурност е популярен в момента. Не съм използвал Service Stack, но постигнах добри резултати с Asp.Net Web Api. Като настрана, WCF може също ReST.

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

arrow_upward
0
arrow_downward

По-рано предоставих подробно обяснение на техническите и философски разлики между ServiceStack и WCF в InfoQ. По отношение на API Design, този по-ранен отговор показва разликите между ServiceStack Message-базиран подход и WCF / Подход на отдалечен метод на WebApi.

SOAP поддръжка

ServiceStack също има Soap Support, но наистина не трябва да използвате 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 Views като функция, така че същата услуга може да се използва от уеб или мобилни клиенти и т.н. Задайте други несвързани въпроси в нов въпрос. - person mythz; 23.05.2013