Правильное размещение службы WCF

Question

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

Я создал API на основе WCF, но не могу определиться с тем, как отделить PL от BL. Я сделал свой сервис тонким, чтобы он содержал только минимум реализации, что-то вроде:

public TagItemResponse TagItem(TagItemRequest request)
{
   return (new ItemTagRequestProcessor()).GetResponse(request);
}

Чем, конечно, возникает первый вопрос, к какому слою принадлежат RequestProcessors? Я думаю, что было бы неправильно называть их фасадом, но в то же время они не имеют ничего общего с презентацией. На данный момент я решил, что они, тем не менее, принадлежат к ЛП. Методы процессора принимают мои DTO (DataContracts) в качестве входных данных, проверяют сообщение запроса (базовый класс), аутентифицируют (базовый класс) и в конечном итоге возвращают один ответ DTO, например:

protected override void Process(TagItemRequest request, TagItemResponse response, Host host)
{
    var profile = ProfileFacade.GetProfile(host, request.Profile);
    var item = ItemFacade.GetItemId(host, request.Item);
    var tags = new List<Tag>();

    foreach (var name in request.Tags)
    {
        var tag = TagFacade.GetTag(profile, name);
        ItemFacade.TagItem(item, tag);
        tags.Add(tag);
    }

    ItemFacade.UntagItem(item, tags);
}

Теперь я спрашиваю себя, зачем мне классы фасада 1: 1, связанные с моими бизнес-объектами. Например, у меня есть HostFacade, который действует как слой между hostDAO и процессорами. Однако он содержит очень мало логики, он просто обрабатывает вызовы DAO.

public static Host GetHost(HostDTO dto)
{
   return HostDAO.GetHostByCredentials(dto.Username, dto.Password);
}

Вопрос: я мог бы также объединить процессоры и фасады, верно?

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

Я нашел f.ex. пример doFactory, где они общались с классами DAO прямо из реализации сервиса. Мне это не очень нравится, так как большинство методов ServiceContract имеют некоторую логику и, таким образом, хорошо подходят для использования с общими базовыми классами.

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

Вероятно, нет единого ответа относительно того, как правильно наложить службу WCF, но, надеюсь, некоторые из вас найдут мнение, которое либо подстроит мои инстинкты, либо прольет для меня новый свет на эту тему. *

Thanx!

Geoffrey

Answer 1

Во-первых, я предполагаю, что под PL вы подразумеваете уровень представления, а не уровень постоянства?

При реализации многоуровневого дизайна приложения основным вопросом всегда должен быть: можно ли заменить реализацию нижнего уровня, не влияя на реализацию слоя (ов) выше.

Обычно это лучше всего иллюстрируется постоянным слоем. Если вы, например, переключитесь с SQL Server 2008 на MySQL, уровень персистентности изменится (конечно). Но необходимы ли изменения в бизнес-уровне? Например, бизнес-уровень перехватывает экземпляры SqlException, которые генерируются только SqlClient? В хорошем дизайне бизнес-уровень вообще не нуждается в изменениях.

Тот же принцип должен применяться к разделению между бизнес-уровнем и уровнем представления.

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

Трудно решить, будет ли иметь фасад между вашим бизнес-уровнем и постоянным уровнем. Я обычно не реализую фасад, потому что он добавляет дополнительный (обычно ненужный) слой косвенности. Кроме того, я не вижу проблемы в вызове методов персистентного уровня непосредственно из методов бизнес-уровня. Если только вы принимаете во внимание тот же принцип: можете ли вы изменить реализацию уровня постоянства, не затрагивая реализацию бизнес-уровня.

С уважением,

Рональд Вильденберг