WCF Дизайн Подход

Question

В моем решении у меня есть проект веб-приложения и проект библиотеки классов, который содержит всю бизнес-логику, и это также действует как слой доступа к данным, поскольку я использую Entity Framework. Это означает, что у меня есть мой edmx в этом слое.

У меня есть около 34 классов в этом проекте библиотеки классов и в среднем по 6 открытых методов в каждом классе. Эти классы вызывались прямо из веб-приложения до сих пор. Нет проблем. Теперь я хочу представить уровень WCF между пользовательским интерфейсом и уровнем бизнес-логики.

Это означает, что мне придется писать методы-оболочки для всех моих методов и выставлять их в службе WCF. Означает ли это, что 34 * 6 = 204 метода (приблизительно) появятся на моем уровне обслуживания как контракты на эксплуатацию? Что касается ОО, я думаю, что это слишком большой класс, и поэтому он чувствует себя не так.

Я знаю, что есть шаблон проектирования Generic Service, но есть ли еще что-то, чего мне не хватает? Пожалуйста, сообщите.

Answer 1

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

Answer 2

Вы можете попробовать службы RIA

http://www.silverlight.net/getstarted/riaservices/

Вот что я использую:

1. Создать службу WCF

2,1.Направьте службу SVC на вашу реализацию, например:

<%@ ServiceHost Language="C#" Debug="true" Service="BusinessLayer.Service" %>

BusinessLayer.Service - это класс в вашем проекте Class.(ссылка в сервисе необходима)

2.2.Укажите поведение службы на контракт:

<service behaviorConfiguration="ServiceBehavior" name="BusinessLayer.Service">
        <endpoint address="" binding="basicHttpBinding" bindingConfiguration="basicHttpBinding" contract="BusinessLayer.IService">
          <identity>
            <dns value="localhost"/>
          </identity>
        </endpoint>
      </service>

Измените имя (BusinessLayer.Service) и контракт (Businesslayer.IService)

Создание интерфейса контракта BusinessLayer.IService (в вашем проекте Class):

пространство имен BusinessLayer {[ServiceContract] открытый интерфейс IService {[OperationContract] void DoWork ();}}

Изменить существующую реализацию, которая использует интерфейс (вот ваш существующий код):

пространство имен BusinessLayer {public class Service: IService {Public void DoWork (){}}}

Answer 3

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

Сказав, что, если у вас нет другого выбора, я бы избегал монолитного класса WCF, охватывающего все общедоступные методы, в которых нуждается ваш пользовательский интерфейс. Прежде всего, я бы представил интерфейс на стороне веб-приложения, чтобы вы могли полагаться на тезисы в пользовательском интерфейсе, а не на конкретные реализации. Далее я хотел бы изучить использование служб WCF REST. Вы можете использовать ServiceRoute, чтобы не вводить какие-либо файлы * .svc. Затем вы можете украсить методы, которые вы хотите предоставить, с помощью атрибутов WebGet / WebInvoke. Это потенциально может сэкономить много кода.

Answer 4

Ну,

У нас есть похожее приложение, но количество классов еще выше. Здесь вы беспокоитесь о том, что вы неохотно предоставляете сериализацию (то есть то, что необходимо для передачи объектов через WCF) в основные классы вашего сервера бизнес-логики.

При условии, что у вас есть классическое трехуровневое приложение, в котором сервер бизнес-логики и клиент обращаются к одной и той же базе данных. Что вам нужно сделать, это просто: 1) убедиться, что все ваши объекты имеют уникальную идентификацию (это может быть строка или Guid) и 2) передать идентификатор объекта во всех вызовах WCF. Это означает, что вы НЕ выставляете какие-либо классы на стороне WCF.

Это может быть гораздо безопаснее, поскольку у вас есть веб-приложение.