Сколько слоев слишком многие?
Поскольку я узнавал о разработке программного обеспечения прошлые 2 года, чем больше я учусь, это кажется, тем с более серыми областями я сталкиваюсь. Одна серая область, с которой у меня есть проблемы прямо сейчас, пытается решить, сколько слоев приложение должно иметь. Например, в приложении WPF MVVM, какой вид разделения на уровни в порядке? Следующее слишком разделяется? Когда я упоминаю, что разделил на уровни, я означаю создавать новую библиотеку классов для каждого слоя.
- Презентация (Представление)
- Модель представления
- Бизнес-слой
- Доступ к данным
- Образцовый слой
- Служебный слой
Или для не приложения MVVM это слишком разделено?
- Presenation
- Бизнес
- Доступ к данным
- Образцовый слой
- Служебный слой
Приемлемо, чтобы выполнить слои вместе и просто создать папки для каждого слоя? Любая окраска этой серой области ценилась бы.
5 ответов
Многоуровневая архитектура: В этой статье описывается конкретный пример архитектуры для клиентских приложений .NET / WPF Rich. Кроме того, архитектура показывает, на каком уровне вы найдете участников шаблона модель-представление-модель представления (MVVM).
В приложении слишком много слоев только в том случае, если сами уровни становятся препятствием для поддержки проекта, а не для улучшения ремонтопригодности.
Рассмотрите следующие области:
- Скорость
- Возможность повторного использования
- Читаемость
- Время разработки
- Скорость модификации (правильные слова для описания этого момента ускользают от меня. Редактировать - Ремонтопригодность была тем, что я искал для [украденный у кого-то другой ответ])
- Размер приложения (масштаб и буквальный размер)
- Ваша команда разработчиков
... затем настройте свою архитектуру в зависимости от того, что из этого вы цените. Возможно, мне не хватает некоторых других важных частей, но идею вы поняли. На самом деле нет правильного или неправильного ответа.
Точное количество слоев, которое слишком много, на 1 больше, чем необходимо.
Ответ: это зависит от ситуации. Во-первых, отдельная библиотека классов не всегда означает отдельный "слой". Слой - это концептуальная группировка связанной функциональности, которая может проявляться или не проявляться в одной сборке.
Количество создаваемых слоев зависит от конкретной задачи. Традиционно, приложение WPF MVVM будет содержать как минимум 3 слоя (Модель, Представление, Модель представления), но на самом деле они могут быть самыми разнообразными. Часто я вижу, что View и ViewModels находятся в одной сборке, а модели - в своей собственной (обычно потому, что объекты Model являются POCO, которые используются в других контекстах)
На самом деле не существует серебряной пули, которая ответит на ваш вопрос, это полностью зависит от вашей проблемы. Преимущество "наслоения" и разделения состоит в том, чтобы повысить сопровождаемость, способствовать повторному использованию кода и повысить общую ясность (вот лишь некоторые из них).
Я бы утверждал, что если вы не достигаете этих целей с вашим текущим решением по наслоению, то у вас есть возможности для улучшения. Если увеличение слоев приводит к снижению ясности или сопровождаемости, значит, вы зашли слишком далеко. Если у вас только один "слой" и он становится раздутым, то у вас есть возможность добавить слой.
Суть в том, что не стоит слишком усердствовать в проектировании ради того, чтобы следовать строгому "шаблону". Если шаблон имеет явные преимущества для вас и вашей проблемы, то реализуйте его, но поймите, почему вы это делаете и какова цель каждого "слоя".