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

Question

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

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

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

Тогда, конечно, возникает первый вопрос: к какому уровню относятся процессоры запросов?Я думаю, было бы неправильно называть их фасадом, но в то же время они не имеют ничего общего с презентацией.На данный момент я решил, что они, тем не менее, принадлежат к ЛП.Методы процессора принимают мои 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, но, надеюсь, есть некоторые из вас с мнением, которое либо согласуется с моими инстинктами, либо прольет для меня какой-то новый свет на этот предмет.

Спасибо!

Джеффри

Answer 1

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

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

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

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

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

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

С наилучшими пожеланиями,

Ronald Wildenberg