Как я могу избежать огромных коммуникационных классов в WCF?
Мое понимание - то, что весь реализующий контракт код должен быть в едином классе, который может стать очень большим, очевидно. Как я избегаю этого? Я действительно предпочитаю иметь несколько маленьких классов, вносящих свой вклад из связи с клиентами, чем единственный громадный класс.
Единственная идея, о которой я мог думать, использует несколько интерфейсов, реализованных единым классом, разделенным partial, но я не думаю, что это действительно решает проблему.
5 ответов
Во-первых, если ваш контракт большой, можно ли их преобразовать в более конкретные сервисные контракты?
Класс реализации контракта может быть реализован как метод точки входа . Вы всегда можете смоделировать реализацию и определить соответствующую абстракцию, а класс реализации контракта службы будет вызывать эту внутреннюю реализацию.
Вы можете использовать Наследование , в зависимости от структуры кода yoru. Обычно вы можете разбить весь код на более мелкие части, помощники, подпрограммы и т. Д.
Как и в любой другой разработке API, вам не нужно / не нужно все в одном месте в одном пакете .
Этот «единственный класс» обычно является фасадом, просто интерфейсом связи.
Таким образом, вы должны не реализовывать всю свою логику в разработчике Службы.
И ваши интерфейсы должны быть как можно меньше (сделайте одну вещь хорошо). Но при необходимости ваш фасад может вызывать несколько классов.
У нас есть около 60 частичных файлов под названием «BeamServer.cs», каждый в подпапке, которая соответствует назначению функций в этом файле. Все вспомогательные классы (или другие вспомогательные файлы), относящиеся к той же области нашей программы, также находятся в этой папке.
Ваш «один класс» представляет вашу «одну бизнес-потребность». Мы обнаружили приятное дополнительное преимущество в том, что если один из членов нашей команды работает над частью «Учет» в BEAM (наше программное обеспечение), то они будут проверять файл «Accounting \ BeamServer.cs» и ничего из остального. команды будет произведено.
РЕДАКТИРОВАТЬ: Кроме того, класс должен только содержать сигнатуры методов (и функции-оболочки, которые просто вызывают base.Channel.DoSomething () ... Любые структуры данных, конечно, будут быть их собственными файлами классов (такими как "Person.cs" или "Employee.cs" или что-то еще).
Если бы вы могли фундаментально изменить свой код, вы могли бы предоставить только одну конечную точку, которая работает с сообщениями запроса / ответа. Таким образом, может быть одна конечная точка и одно определение службы, которое принимает (возможно, производное) сообщение запроса и возвращает ответное сообщение. Тогда ваш интерфейс к службе будет просто одним методом, а в реализации на стороне сервера вы направите этот объект запроса в фактическую реализацию службы (возможно, определенную фабрикой), возможно, используя метаданные в сообщении запроса (или даже его тип - name), чтобы определить, какая служба вызывается.
Итак, ваш интерфейс конечной службы будет просто иметь такой метод:
public interface IServiceRequestor
{
Response ProcessRequest(Request request);
}
Это позволит вам обрабатывать возможно неограниченное количество открытых служб без необходимости знать, какими они будут во время компиляции / разработки, а также избежать распространение методов службы, определяющих доступные вызовы служб