Предотвращение классов бога веб-сервиса

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

Это наводит на мысль, что ваш WebService обслуживает две роли: логику и интерфейс. ... но на самом деле он, вероятно, должен служить только одному, интерфейсу в вашей логике.

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

ОБНОВЛЕНИЕ:

С точки зрения того, почему вы должны проводить рефакторинг и / или как вы должны проектировать свою библиотеку классов, некоторые из принципов SOLID Principles могут быть вам полезны . В частности:

• Принцип единой ответственности
• Принцип разделения интерфейсов

Проверьте ссылку выше, и там вы найдете краткое изложение всех принципов.

здесь ' s некоторые SO обсуждения по этому поводу. Если у кого-то есть ссылки получше, дайте мне знать, ура

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

About your options/comments:

Option 1: I understand your concern, but you need to draw the line somewhere. You shouldn't just go on and end up in the future with a 1000 operations service, this time not for your code but for the caller. Also, there might be reason for the high number of operations in your scenario, just make sure to avoid a chatty API as you really don't want multiple round trips going on for the same operation.

Option 2 + regions: as u are saying, u have separate pieces of the app. Those shouldn't belong to the same class, and naming a few patterns won't really sell it well. Check this series, as its a journey on many of these things http://blog.wekeroad.com/category/mvc-storefront (do it from chapter 1) - it helped me a lot. U can also check this e-book on solid - http://www.lostechies.com/content/pablo_ebook.aspx. There is a lot of reason to many of the things currently going on, but none of them can really be transmitted in a catchy phrase.

As others have said, your service code should be just a tiny layer that translates to a service appropriate format and your application logic. Consider learning unit tests, those will seem ridiculous when u have been working with code like that, since it pretty much prevents u from using it well. That will continually remind u/point u to where u have your code all tied up.

Предложения по ре-факторингу:

Вам не обязательно иметь 131 рабочий контракт в одном сервисном контракте. Разделите их на один контракт на обслуживание для каждой функциональной области. В итоге у вас будет несколько конечных точек в вашем сервисе, но разве это действительно важно?

Поместите все сервисные контракты и контракты данных в сборку «только контракта». Поместите классы реализации в другую сборку (или несколько сборок с разбивкой по функциям). Поместите фасад веб-службы в еще одну сборку, которая содержит только файл web.config и множество пустых файлов .svc , которые указывают на классы реализации.

Пример файла переработанный файл .svc , без кода программной части (так как "код программной части" находится в другой сборке):

<%@ ServiceHost Service="Fully.Qualified.Name.Of.Implementation.Class" %>

Дополнительным преимуществом такого разделения кода является то, что вашему клиентскому приложению не нужно возиться с svcutil.exe и ссылками на службы. Вы можете напрямую ссылаться на сборку контракта и использовать ChannelFactory для вызова службы.

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

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

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

Независимо от того, что вы решите относительно интерфейса службы, вам следует серьезно подумать о том, чтобы преобразовать свой сервис во что-то более управляемое. В идеале должна существовать модель предметной области, которая реализует все поведение службы. Такая модель предметной области будет состоять из множества классов, каждый со своими отдельными обязанностями. Тогда служба будет просто фасадом для модели предметной области. Если все операции заключаются в делегировании их реализации модели предметной области, 131 операция не является слишком неуправляемой.

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

Если, с другой стороны, вы найдете некоторую логическую группировку, чтобы упорядочить свои частичные классы вы уже на пути к более глубокой модели. В таком случае, почему бы вместо частичных классов не объединить такие группы в концепции, которые можно смоделировать в реальных, отдельных классах?

В любом случае я согласен с Робертом: услугу необходимо реорганизовать.