Лучший дизайн приложения asp.net WCF

Question

Я работаю с финансовым приложением и ищу лучшее решение для разработки моего приложения.

У нас есть сотни хранимых процедур, в которых находится большая часть всей нашей бизнес-логики. У нас есть проекты веб-служб WCF, созданные с использованием фабрики программного обеспечения веб-служб (http://servicefactory.codeplex.com/). У нас есть хранимые процедуры, созданные почти для всего (таблиц, раскрывающихся списков и т. Д.), И каждый из этих хранимых процедур имеет собственный веб-сервис, который может вызываться веб-приложением. Каждый веб-сервис - это очень простой метод, который вызывает хранимую процедуру с точными параметрами веб-сервиса.

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

У кого-нибудь еще есть похожая среда? Как это реализовано на вашем конце?

Answer 1

Это классический компромисс между:

• имея небольшие, сфокусированные сервисы, которые выполняют одно и только одно - вы в конечном итоге получаете много
• иметь большие сервисы с множеством методов, которые делают много вещей - но у вас их меньше

В целом, я бы сказал, что я предпочел бы подход № 1 - сделать ваши сервисы красивыми, небольшими и простыми в обслуживании, и уважать принцип единой ответственности - сервис (или класс) должен выполнять одно и только одно.

Возможно, вы сможете объединить несколько вызовов, которые по логике принадлежат друг другу, в один сервис с несколькими вызовами, но как только сервис получает слишком много вызовов (более 10-15, 20?), Он становится громоздким и вам приходится менять его слишком часто, потому что он выполняет так много задач....

Answer 2

Мое мнение основано на том, что предполагается использовать сервисы - собираются ли они обслуживать внешние приложения сервера или предназначены только для использования в вашем приложении?

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

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