Лучшая практика для больших услуг WCF?

Question

Какова лучшая практика для написания довольно большого wcf-сервиса, содержащего много OperationContracts и DataContracts?

Как бы я разделил функциональные области на несколько контрактов, было бы лучше создать конечную точку для каждой функциональной области?

Есть ли способ сохранить источник для разных частей отдельно, но при этом использовать только один сервис для всех из них?

Где я могу получить хорошую информацию о том, как планировать контракты, что включать, как разбивать ...?

Answer 1

Это был большой вопрос, связанный с услугами с момента их создания. Успешно выполненная SOA - это план SOA, о котором вы говорите. Сказав это, я всегда больше склонялся к разделению сервисов, но использовал их сложным образом. То есть несколько конечных точек, когда у вас есть несколько контрактов, но большинство из них потребляются только несколькими конечными точками, которые потребляются не обслуживающими абонентами. (вау, это было глотком, имело ли это смысл?)

Кроме того, я бы посоветовал иметь как можно меньше контрактов. Слишком много контрактов может привести к плохой управляемости. Хороший дизайн контракта поможет ограничить количество конечных точек и количество обращений в сервис. Удаление концепций ОО из контрактного дизайна - один из способов сделать это. Проектирование контракта само по себе является большой темой, но достаточно сказать, что благодаря хорошему планированию контракта (заранее), получается хороший дизайн сервиса.

Мартен Маллендер пишет отличный блог о дизайне WCF и должен прочитать. Есть также несколько замечательных книг по SOA / WCF.

Несколько хороших книг:

• Pro WCF: практическая реализация Microsoft SOA
• Программирование WCF

Answer 2

Я сойду с пути и скажу, что я использовал монолитные контракты WCF, функционально разделенные контракты (максимум десять методов в соответствии с рекомендациями Ювала в его книге), а также я попробовал архитектуру обработки сообщений, где служба имеет единственный метод, который принимает базовое сообщение, и обработчики, которые «знают», как развернуть и обработать сообщение после того, как оно пересекает провод.

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

http://ayende.com/Blog/archive/2008/03/30/Hibernating-Rhinos-8--Going-Distributed-amp-Building-our-own.aspx

Тем не менее, если вы уже говорите «мне нужен большой сервис WCF», то переход к одному методу, вероятно, не подойдет вам. Если это так, то услуги WCF Ювала Лоуи - это стандарт, который вы должны соблюдать в своем дизайне.

Answer 3

Это было полезно для меня, оно взято с веб-сайта idesign.net и его автором является Ювал Лоуи:

Стандарт кодирования WCF

Answer 4

У меня здесь есть пост о том, как отдельные операции должны отличаться от традиционных операций с кодом:

http://www.iserviceoriented.com/blog/post/Introduction+to+Service+Oriented+Architecture.aspx

В конечном итоге вы должны выполнять операции только для реальных деловых событий. Если вы когда-нибудь остановитесь и подумаете «Мне нужно включить поддержку транзакций в моем веб-сервисе», это означает, что вы не спроектировали операцию с достаточно широким охватом. Вы никогда не должны включать поддержку транзакций веб-службы.

Я настоятельно рекомендую блог Билла Пула для концепций SOA более высокого уровня. Вот пост, чтобы начать:

http://feeds.feedburner.com/~r/BillPoolesCreativeAbrasion/~3/328955489/service-contract-stability.html

Answer 5

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

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

Одна услуга для учетной записи, одна для продукта и т. Д.

Не уверен, что кто-то подумает об этом, хотя ...