Стоит ли использовать 3-уровневую архитектуру для небольших приложений

Question

Я работаю над относительно небольшим asp.net веб-приложением, и мне интересно, действительно ли есть необходимость использовать полную n-уровневую архитектуру.Для получения представления о размере;существует около 20 таблиц базы данных.

В прошлом я использовал двухуровневый подход, при котором бизнес-логика и доступ к данным группировались вместе в единую библиотеку классов с помощью was asp.net веб-приложение, формирующее уровень пользовательского интерфейса, и это, казалось, работало нормально.

Существует ли пороговый размер или какое-то эмпирическое правило, при котором вы должны использовать n-tier?

Answer 1

Возможно, сейчас она относительно невелика, но как вы думаете, может ли она вырасти в будущем?Конечно, вы должны быть прагматичны, но если у вас уже есть естественные разделители внутри вашей отдельной сборки, то ее довольно легко разделить на две или более сборок.Если сами классы сочетают бизнес-логику и доступ к данным, то у вас будет больше работы.Однако я бы сказал, что написать логику доступа к данным в одной сборке, а бизнес-логику - в другой, параллельно, если требуется, почти не сложнее, чем изначально записать все это в одном месте.

Answer 2

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

Все дело в будущих затратах.В настоящее время простое программирование на ходу, безусловно, самое дешевое, но оно не очень хорошо реагирует на изменения.При многоуровневом планировании возникают первоначальные затраты, но оно может справиться с изменениями и вырвать реализации всего уровня лучше, чем при первом подходе.

Таким образом, ваше эмпирическое правило определяется тем, кто заплатит за изменение и когда.

Answer 3

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

Будьте проще, создайте свои три слоя, я предлагаю вам попробовать LINQ to SQL, это упрощает создание DAL, а затем вы можете сосредоточиться на создании тонкого пользовательского интерфейса и BLL, который справится с тяжелой работой.Это не займет у вас так много времени, и это позволит позже провести модульное тестирование.

Answer 4

Существует ли пороговый размер или какое-либо эмпирическое правило где вы должны использовать n-уровень?

Насколько мне известно, нет ни одного, но я выброшу это:если есть шанс, что это веб-приложение может вырасти (или сменить серверные части) и / или кто-то другой в конечном итоге может его поддерживать, я бы рассмотрел возможность использования n-уровневого подхода.

Answer 5

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

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

Сохранить все разделенным не так уж сложно, поэтому, как я уже говорил ранее, просто сделайте это возможным.