Разработка контрактов и операций с данными WCF

Question

Я начинаю проектировать сервисную шину wcf, которая теперь мала, но будет расти по мере роста нашего бизнеса, поэтому меня беспокоят некоторые растущие проблемы, а также я стараюсь не слишком сильно YAGNI. Это платформа электронной коммерции. Проблема в том, что у меня слишком много мыслей о том, куда положить вещи. Я дам сценарий, чтобы продемонстрировать все мои вопросы.

У нас есть сайт электронной коммерции, который продает продукты и в конечном итоге доставляет их. Для этого у нас есть сервис PlaceOrder, который, помимо других параметров, ожидает объект Address, который в этом контексте (наш сайт размещает заказ) состоит из City, Street и ZipCode.

Мы также работаем с партнерами, которые используют нашу платформу только для продажи продуктов. Они заботятся о доставке. Для этого сценария у нас есть сервис PlaceOrderForPartner, который, помимо других объектов, ожидает объект Address. Однако в этом контексте (партнер, размещающий заказ) объект Address состоит из различной информации, которая относится только к заказу, размещенному партнером.

Учитывая этот сценарий, у меня есть несколько вопросов:

1) Как организовать эти объекты DataContracts в пространствах имен и папках в моем решении? Я думал о том, чтобы иметь папку для контекста (Партнер, Клиент и т. Д.) Для хранения услуг и DataContracts.

Итак, я бы получил

- MySolution.sln
-    Partner (folder)
-        PartnetService.svc
-    DataContracts (folder)
-        Address
-    Customer (folder)
-        Customer.svc
-    DataContracts (folder)
-        Address

Используя этот способ, у меня будет пространство имен для размещения всех моих контекстно-зависимых контрактов данных.

2) А как насчет сервисного дизайна? Должен ли я создать сервис для каждого, который мог бы разместить и заказать и создать метод PlaceOrder внутри него, например:

Partner.svc / PlaceOrder
Customer.svc / PlaceOrder

или создайте сервис заказов с помощью PlaceOrderForPartner и PlaceInternalOrder следующим образом:

Order.svc / PlaceOrderForPartner
Order.svc / PlaceOrderForCustomer

3) Если я выберу первый вариант в последнем вопросе, что мне делать с операциями, которые выполняются в заказе и являются общими для Партнера и Клиента?

4) Должен ли я поместить DataContracts и Service в одну сборку? По одному на каждого? Все с реализацией сервиса?

5) Как назвать входные и выходные сообщения для операций? Должен ли я использовать сами объекты или перейти к шаблону OperationNameRequest и OperationNameResponse?

Суть в том, что мой большой вопрос таков: как "организовать" контракты данных и службы, участвующие в создании службы?

Заранее спасибо за любые мысли по этому поводу

Answer 1

Помимо того, что упомянул TomTom, я также хотел бы добавить сюда свои 2 цента:

Мне нравится структурировать свои решения WCF следующим образом:

Контракты (библиотека классов)
Содержит все контракты на обслуживание, операции, неисправности и данные. Может использоваться совместно сервером и клиентом в чистом сценарии .NET-to-.NET

Реализация службы (библиотека классов)
Содержит код для реализации сервисов и любые вспомогательные / вспомогательные методы, необходимые для достижения этой цели. Больше ничего.

Сервисный хост (ы) (необязательно - может быть Winforms, Консольное приложение, NT Service)
Содержит сервисные хосты для отладки / тестирования или, возможно, также для производства.

Это в основном дает мне серверную часть вещей.

На стороне клиента:

Клиентские прокси (библиотека классов)
Мне нравится упаковывать свои клиентские прокси в отдельную библиотеку классов, чтобы их можно было повторно использовать в нескольких реальных клиентских приложениях. Это можно сделать с помощью svcutil или «Добавить ссылку на службу» и вручную настроить получившиеся в результате ужасные файлы app.config или вручную внедрить клиентские прокси-серверы (при совместном использовании сборки контрактов), используя конструкции ClientBase<T> или ChannelFactory<T>.

1-n реальных клиентов (любое приложение)
Как правило, будет ссылаться только на сборку прокси-клиентов или сборку контрактов, если она используется совместно. Это могут быть ASP.NET, WPF, Winforms, консольное приложение, другие службы - вы называете это.

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

Это было вдохновлено фильмом Мигеля Кастро Extreme WCF на DotNet Rocks TV с Карлом Франклином - очень рекомендуется снимать экран!

Answer 2

Вы начинаете неправильно на самом высоком уровне.

• Это должен быть не сервис "PlaceOrder", а "OrderManager". Возможно, вы захотите добавить дополнительные сервисные функции позже - например, запрос заказов, отмена заказов, изменение заказов - кто знает. В общем, я бы оставил небольшое количество «служб» (.svc) и добавил бы туда методы. В противном случае вы получите огромные накладные расходы на их использование в коде - без какой-либо реальной выгоды.

• Почему разграничение между партнерами и клиентами? Я уверен, что за 15 минут проектирования данных вы можете разбить все на одну структуру данных, чтобы у вас был только один сервис. Если нет ... сделайте это двумя методами на одном интерфейсе, ограничьте его безопасностью. Но я серьезно не хотел бы две программы для этого. Вместо этого есть два поля адреса - «Адрес» и «PartnerInfo», и можно установить только одно (другое должно быть нулевым), отмеченное в логике.

• Разделить на два проекта. Интерфейсы, контракты на передачу данных входят в отдельный проект (blabalbla.Api), так что клиенты могут получить DLL, если захотят - по крайней мере, это значительно облегчает вашу задачу, вы можете полагаться на «общий тип», не нужно создать оболочки внутри. Позволяет намного лучше тестировать (так как подпроекты не забывают регенерировать обертки .... что может привести к ошибкам при их тестировании).

• Я всегда помещал реализацию в проект "blabla.Service". Url будет «Services.blabla.com/» в поддомене (или «api.blabla.com», в основном зависит от настроения, но в последнее время я в основном обращаюсь к api) - отделяет тройки от основного веб-сайта.