Какова наилучшая практика для написания довольно большой службы wcf, содержащей много OperationContracts и DataContracts?
Как отделить функциональные области от нескольких контрактов, было бы лучше создать конечную точку для каждой функциональной области?
Есть ли способ сохранить источник для разных частей отдельно, но все же использовать только одну услугу для всех из них?
Где я могу получить хорошую информацию о том, как планировать контракты, что включать, как разделить...?
Это был большой вопрос, связанный с сервисами с момента их создания. SOA успешно завершена, SOA запланирована в той степени, в которой вы говорите. Сказав это, я всегда больше склонялся к разделению служб, но использовал их в совокупности. То есть, несколько конечных точек, когда у вас несколько контрактов, но большинство из них потребляется только несколькими конечными точками, которые потребляются не обслуживающими абонентами. (ничего себе, это был глоток, это даже имело смысл?)
Кроме того, я бы посоветовал иметь как можно меньше контрактов. Слишком много контрактов может привести к плохой управляемости. Хороший дизайн контракта поможет ограничить количество конечных точек и вызовов службы. Одним из способов этого является удаление концепций ОО из проекта контракта. Контрактный дизайн - это массовая тема сама по себе, но достаточно сказать, что благодаря хорошему контракту (впереди), приходит хороший дизайн обслуживания.
Maarten Mullender пишет отличный блог в дизайне WCF и должен читать. Кроме того, появляются и некоторые замечательные книги SOA/WCF.
Некоторые хорошие книги:
Это было полезно для меня, это происходит с сайта idesign.net, и он был автором Juval Lowy:
Я пойду с трека здесь и скажу, что использовал монолитные контракты WCF, функционально разделенные контракты (максимум десять методов по рекомендациям Juval в его книге), и я также пробовал архитектуру обработки сообщений, служба имеет единственный метод, который принимает базовое сообщение и обработчики, которые "знают", как разворачивать и обрабатывать сообщение после того, как оно пересекает провод.
Я большой поклонник последнего, если у вас есть .NET по обеим сторонам забора. У Орена есть скринкаст по идее с кодом. Я не знаю, каковы ваши потребности, но это работает на меня.
Тем не менее, если вы уже пришли из "Мне нужна большая служба WCF", то переход к одному методу, вероятно, не собирается сокращать его для вас. Если это правда, то Juval Lowy Programming WCF Services является стандартом, который вы должны придерживаться в своем дизайне.
У меня есть сообщение о том, как отдельные операции должны отличаться от традиционных операций с кодом:
http://www.iserviceoriented.com/blog/post/Introduction+to+Service+Oriented+Architecture.aspx
Вы должны работать только с действиями для реальных деловых событий. Если вы когда-нибудь остановитесь и подумаете: "Мне нужно включить поддержку транзакций в моем веб-сервисе", это означает, что вы не разработали операцию с достаточно широким охватом. Вам никогда не придется включать поддержку транзакций веб-сервисов.
Я очень рекомендую блог Билла Пула для концепций SOA более высокого уровня. Вот сообщение для начала:
Я знаю, что это старый пост, но я думаю о сервисах так же, как я думаю об объектах в программировании.
Держите их на своём минимуме за то, что они должны делать. Конечно, не до крайности, но я принимаю решения на основе данных.
Одна услуга для учетной записи, одна для продукта и т.д.
Не уверен, что кто-нибудь подумает об этом, хотя...