архитектура wcf - как гибко оформить контракт на обслуживание

Question

У меня есть несколько объектов, таких как: Customers, Orders, Invoices.

Для каждого из них я сгруппировал их операции CRUD и несколько других в интерфейсах, таких как: ISvcCustomerMgmt, ISvcOrderMgmt, ISvcInvoicesMgmt, ISvcPaymentsMgmt.

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

1. один для внутреннего использования ISvcInternal: ISvcCustomerMgmt, ISvcOrderMgmt, ISvcInvoicesMgmt //,maybe more in the future
2. один длявнешнее использование (третьи стороны) ISvcExternal: ISvcCustomerMgmt //,maybe more in the future

Итак, мои реальные услуги выглядят так: 1) SvcInternal: ISvcInternal, 2) SvcExternal: ISvcExternal.

Когда я вижу SvcInternal реализация, она становится больше с большим количеством операций.

Является ли этот метод достаточно гибким?Вы рекомендуете другой подход к их разделению?Не стесняйтесь поделиться своими мыслями.

Спасибо.

Answer 1

Если мне нужно реализовать это, я бы сказал, что я помещу весь код и Операции в Worker Manager или Fascade Layer ..., который будет состоять из всех операций ... (Реальная логика кодирования).

мой сервис будет только тонким клиентом, который будет только передавать запрос на уровень Fascade .... Это позволяет мне повторно использовать большое количество кода ... и также позволяет мне использовать один и тот же метод в более чем одном сервисе без переопределения .... Хотя один момент, почему вы не используете различие между вашими внутренними и внешними службами с разными привязками ... например даже если вы собираетесь использовать WSHttpBinding или BasicHttpBinding для обеих служб, создайте разные конечные точки и привязку для них ....

с точки зрения Code Hirerachy, моя идея заключалась бы в использовании hirerachy папок и пространств имен, чтобы дифференцировать ч / б это ... например. Пространство имен. Интерфейс. Внутренний и наоборот ...

надеюсь, это поможет.

Answer 2

Это может быть бесконечная дискуссия ... Как вы решите сгруппировать свои сервисные операции, зависит только от вас.

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

Другой вариант - иметь один сервис для каждого типа объекта или для совокупного корня. Совокупный корень - это объект, имеющий идентификатор и управляемый независимо от других объектов. Пример: у вас может быть сущность Invoice и сущность InvoiceLine; тогда объект Invoice является агрегированным корнем, а объект InvoiceLine - нет, поскольку он не может существовать без Invoice - следовательно, он не является независимым.

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

Answer 3

В нашей компании услуги состоят из 3 сборок:

1) «контрактная» сборка, которую мы называем [Company]. [Project] .Contract.Эта сборка содержит объекты DTO (Domain), определения интерфейса и класс Client для доступа к службе.Эта сборка может быть предоставлена ​​тем, кто хочет использовать ваш сервис.

2) «бизнес» сборка, которую мы называем [Company]. [Project] .Business.Эта сборка предоставляет фабричный класс, который возвращает интерфейсы для внутренних рабочих классов.

3) «сервисная» сборка, которую мы называем [Company]. [Project] .Service для традиционной службы SOAP или [Company]. [Project] .Rest в случае службы REST, это «фасад», который публикует интерфейсы службы и покрывает логику транспорта и протокола.

Объединение всех функций в одной службе является хорошим вариантом дляНачнем с того, что скоро вы обнаружите, что некоторые классы естественным образом связаны друг с другом, так что вы, вероятно, получите ряд специфичных для домена сервисов.

Теперь, WCF имеет эту прекрасную концепцию конфигурации, но те, кто имеет опыт работы с этим, согласятся, что это может быть очень утомительным и подверженным ошибкам, особенно когда ваша SOA становится более сложной (как это всегда бывает,в конце концов).Это всегда приводит к очень сложным конфигурациям, умноженным на различные среды (разработка, тестирование, подготовка, производство), в которых будут работать сервисы. Нет необходимости говорить, что это может привести к ошибкам.

Чтобы справиться с этим, мы используемплатформа broobu, которая позволяет практически нулевую конфигурацию для служб WCF с использованием WS-Discovery и динамической генерации прокси-сервера, единственным недостатком этого решения является то, что вы предпочтительно используете службы, размещенные на IIS, с AppFabric 1.1.Таким образом, вы используете IIS для настройки служб: гораздо безопаснее (так как вы не будете использовать файлы конфигурации XML) и гораздо более масштабируемыми.