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

Question

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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