Как моя команда должна решить между 3-уровневой и 2-уровневой архитектурой?
Моя команда обсуждает будущее направление, мы берем наши проекты. Половина команды верит в чистую 3-уровневую архитектуру в то время как другая половина пользы 2-уровневая архитектура.
Предположения проекта:
- Бизнес-приложения предприятия
- Бизнес-логика необходима между пользователем и базой данных
- Необходимое подтверждение правильности данных
- Для обслуживания широкого круга запросов (предпочитают УСПОКОИТЕЛЬНЫЕ сервисы),
- Многолетний план технического обслуживания
- Поддержка сотни пользователей
3-уровневая польза команды:
- Уровень Persistant <==> Доменный слой <==> уровень UI
- Сервисная граница, по крайней мере, между персистентным слоем и доменным слоем. Доменный слой мог бы иметь сервисную границу между ним.
- Переводы между каждым слоем (чистят разделение DTO),
- Ручное постоянство списка, если мы не можем найти творческую еще изящную автоматизацию
2-уровневая польза команды:
- Уровень Entity Framework + WCF Data Service <==> уровень UI
- Бизнес-логика сохранена в перехватчиках Услуги передачи данных WCF
- Минимальный перевод между слоями - способствует более быстрому кодированию
Таким образом, это - высокоуровневый аргумент. Какие соображения мы должны принять во внимание? Какие события Вы имели с любым подходом?
2 ответа
Есть время и место для предварительного проектирования, и это может сделать только опытный архитектор, который знает все тонкости вашего проекта. Что касается меня, если есть какие-то сомнения или все может пойти по другому пути, я понимаю это так:
- Начните с малого (один уровень)
- Используйте разработку через интерфейс и хороший SRP, гибкий дизайн и т. Д.
- После того, как у вас будет рабочий прототип , проведите сеанс редизайна. Выбор должен быть более ясным.
YMMV.
Я не верю, что две стороны на самом деле так далеко друг от друга. Мне кажется, что двухуровневый подход предполагает больший упор на презентацию и желание, чтобы сервисы делали всю тяжелую работу. У сервисов, вероятно, будет еще один уровень доступа к данным, так что это еще один трехуровневый подход. Это также то, что мы предпочитаем в моей работе, потому что внесение изменений в сервисы часто не требует каких-либо изменений для потребителей, если мы поддерживаем тот же интерфейс.
Тем не менее, я думаю, что это должно быть намного ниже в списке приоритетов, о которых следует беспокоиться. Многоуровневый подход сам по себе не поможет. Важно то, как эти уровни построены. Я считаю, что для всех гораздо важнее согласовать методы кодирования. Такие вещи, как внедрение зависимостей, разделение проблем, инверсия управления, модульное тестирование, имитация и т. Д. Эти вещи намного важнее, чем забота о том, сколько уровней существует. Как только они будут размещены, ярусы последуют за ними естественным образом.