Как я могу избежать огромных классов общения в WCF?

Question

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

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

Answer 1

Возможно, вы захотите использовать Наследование , в зависимости от структуры вашего кода. Обычно вы можете разбить весь код на более мелкие части, помощники, подпрограммы и т. Д.

Как и в любой другой API-разработке, вам не нужно / не нужно все в одном месте в одном пакете.

Answer 2

Если бы вы могли фундаментально изменить свой код, вы могли бы предоставить только одну конечную точку, которая работает с сообщениями запроса / ответа. Таким образом, может быть одна конечная точка и одно определение службы, которое принимает (возможно, производное) сообщение запроса и возвращает ответное сообщение. Ваш интерфейс в сервисе тогда будет просто единичным методом, и в реализации на стороне сервера вы перенаправите этот объект запроса в фактическую реализацию сервиса (возможно, определяемую фабрикой), возможно, используя метаданные в сообщении запроса (или даже «тип имя), чтобы определить, какая служба вызывается.

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

public interface IServiceRequestor
{
  Response ProcessRequest(Request request);
}

Это позволяет вам обрабатывать неограниченное количество доступных служб без необходимости знать, какими они будут во время компиляции / разработки, а также избегать распространения методов Service, определяющих доступные вызовы службы

Answer 3

Во-первых, если ваш контракт большой, могут ли они быть реорганизованы в более конкретные контракты на обслуживание?

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

Answer 4

У нас есть около 60 частичных файлов, называемых «BeamServer.cs», каждый в подпапке, которая соответствует назначению функций в этом файле. Любые вспомогательные классы (или другие вспомогательные файлы), относящиеся к той же области нашей программы, также находятся в этой папке.

Ваш «один класс» представляет вашу «одну бизнес-потребность». Мы нашли приятное побочное преимущество в том, что если один из членов нашей команды работает над частью «Бухгалтерия» BEAM (нашего программного обеспечения), то они проверят файл «Accounting \ BeamServer.cs» и ничего из остальных. команды будет осуществлено.

РЕДАКТИРОВАТЬ: Кроме того, класс должен только содержать сигнатуры методов (и функции-обертки, которые просто вызывают base.Channel.DoSomething() ... Любые структуры данных, конечно, будут своими собственными файлами классов (такими как "Person"). .cs "или" Employee.cs "или любой другой).

Answer 5

Этот «единственный класс» обычно является фасадом, просто интерфейсом связи.
Поэтому вы должны , а не реализовать всю свою логику в реализации службы.

И ваши интерфейсы должны быть как можно меньше (делайте 1 вещь хорошо). Но при необходимости ваш фасад может вызывать несколько классов.