Антишаблон SOA или WCF

Я думаю, что Вы правы. В моем текущем присвоении (веб-разработка) каждый доступ к базе данных реализован как услуга. Мы - "ЧИСТЫЙ SOA", как сказал ведущий архитектор... Ничего себе!

В фактах это добавляет большую сложность ко всему. Когда я хочу считать содержание простой таблицы, я должен генерировать что-то как 8 проектов, 42 файла, 8 блоков и вероятно 9 файлов конфигурации!

Большая сложность, поскольку я сказал. Возможности - кто-то, где-нибудь забудет один файл... Представление простого процесса как услуга глупо.

В моих книгах необходимо выставить процессы как услуга когда:

• Много приложений с помощью различных языков и платформ должны назвать материал.
• Существует больше чем одна включенная платформа (Windows, Unix...).
• Обработанные данные являются ядром предприятия.

Кроме того, заметьте, что сервис должен быть РАЗРАБОТАН, чтобы быть сервисом, и что разработка сервиса, по крайней мере, так же сложна как разработка библиотеки: обнаружение ошибок должно быть тщательно обработано, вход должен быть достаточно гибким, документация должна быть подробной и т.д.

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

Очень интересный вопрос. 1 точка: o)

SOA как понятие является прекрасной идеей.

SOA, как реализовано использующий HTTP-WS/BPEL и др., является шуткой, которая имеет право умирать в моем не так скромное представление. Я прекратил относиться к системе серьезно вскоре после изучения, что их единственное понятие распределенных транзакций является транзакциями компенсации... bzzt NEXT!!

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

Я предлагаю очень хорошую загружаемую книгу, которая объясняет действительно, каков SOA:

http://www.infoq.com/minibooks/enterprise-soa

Затем Вы могли прочитать эту интересную запись в блоге

С уважением

Я знаю два основных антипаттерна:

• Непосредственное отображение объектов из вашего бизнес-уровень через ваш уровень сервиса
• Предоставление определенных детализированных методов, таких как те, что на вашем бизнес-уровне

Рекомендуется, чтобы ваш уровень сервиса содержал общие, общие методы, а они принимали и возвращали несколько большие запросы и ответы на основе сообщений. Цель состоит в том, чтобы предоставить довольно общий интерфейс, не делая слишком больших предположений о том, как будет использоваться служба, и не требуя многочисленных вызовов для достижения базовой функциональности. Постарайтесь свести к минимуму количество обращений к веб-службам.

Вот отличный совет на высоком уровне: http://apparchguide.codeplex.com/Wiki/View. aspx? title = Chapter% 2013% 20-% 20Service% 20Layer% 20Guidelines

Вот конкретный пример типа классов «сообщений», о которых идет речь в руководстве, и того, как реализовать его в WCF: http : //dotnet.org.za/hiltong/pages/windows-communication-foundation-tutorial-part-3-messaging-messagecontracts.aspx