Как моя команда должна выбирать между 3-уровневой и 2-уровневой архитектурой? - PullRequest
5 голосов
/ 27 апреля 2010

Моя команда обсуждает будущее направление наших проектов. Половина команды верит в чистую 3-уровневую архитектуру, а другая половина предпочитает 2-уровневую архитектуру.

Предположения проекта:

  1. Корпоративные бизнес-приложения
  2. Необходима бизнес-логика между пользователями и база данных
  3. Проверка данных необходима
  4. Сервис-ориентированные (предпочитают RESTful-сервисы)
  5. Многолетний план обслуживания
  6. Поддержка сотен пользователей

3-уровневая команда Сувениры:

  1. Постоянный уровень <==> Уровень домена <==> Уровень пользовательского интерфейса
  2. Граница обслуживания между по меньшей мере постоянным уровнем и уровнем домена. Доменный слой может иметь служебную границу между ним.
  3. Переводы между каждым слоем (чистое разделение DTO)
  4. Устойчивость ручного рулона, если мы не сможем найти креативную, но элегантную автоматизацию

2-уровневая команда Сувениры:

  1. Entity Framework + уровень службы данных WCF <==> Уровень пользовательского интерфейса
  2. Бизнес-логика хранится в перехватчиках службы данных WCF
  3. Минимальный перевод между слоями - предпочтение более быстрому кодированию

Так что это аргумент высокого уровня. Какие соображения мы должны принять во внимание? Какой опыт у вас был с любым подходом?

Ответы [ 2 ]

4 голосов
/ 27 апреля 2010

Есть время и место для предварительного проектирования, и его может сделать только опытный архитектор, который знает все тонкости вашего проекта. Для меня, если есть все сомнения или если это может пойти в любом случае, я принимаю это так:

  1. Начните с малого (один слой)
  2. Используйте разработку на основе интерфейса и хороший SRP, гибкий дизайн и т. Д.
  3. Когда у вас есть рабочий прототип, проведите сеанс редизайна. Выбор должен быть намного понятнее.

YMMV.

2 голосов
/ 29 апреля 2010

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

Однако, несмотря на все сказанное, я думаю, что это должно быть намного ниже в списке приоритетов, о которых нужно беспокоиться. Многоуровневый подход не поможет вам сам по себе. Важно то, как эти уровни построены. Я чувствую, что для всех гораздо важнее договориться о методах кодирования. Такие вещи, как внедрение зависимостей, разделение проблем, инверсия управления, модульное тестирование, насмешки и т. Д. Эти вещи гораздо важнее, чем забота о количестве уровней. Уровни будут следовать естественным образом, как только они будут на месте.

...