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

Question

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

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

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

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

Answer 1

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

• , имеющих маленьких, ориентированных услуг, которые делают одно и только одно - вы в конечном итоге с большим количеством «Em
• , имеющих большие услуги с большим количеством методов которые делают много вещей, - но у вас их меньше.

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

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

Answer 2

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

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

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