Стоит ли использовать 3-уровневую архитектуру для небольших (ish) приложений
Я работаю над относительно небольшим asp.net веб-приложение и мне интересно, действительно ли нужно использовать полную N-уровневую архитектуру. Для идеи размера; есть около 20 таблиц базы данных.
в прошлом я использовал 2-уровневый подход, где бизнес-логика и доступ к данным сгруппированы вместе в одну библиотеку классов с asp.net веб-приложение, формирующее уровень пользовательского интерфейса, и это, казалось, работало нормально.
есть порог или некоторые правила большой палец, где вы должны использовать n-уровень?
5 ответов
Он может быть относительно небольшим сейчас, но вы думаете, что он может вырасти в будущем? Конечно, вы должны быть прагматичными, но если у вас уже есть естественные разделения беспокойства в пределах одной сборки, тогда довольно легко разделить это на две или более сборки. Если сами классы объединяют бизнес-логику и доступ к данным, у вас больше работы на руках. Однако я бы сказал, что почти больше не нужно писать логику доступа к данным в одной сборке и в вашем бизнесе логика в другом, параллельно если требуется, чем писать все это в одном месте в первую очередь.
Если вы ожидаете роста или изменения любого рода, это поможет укрепить явные уровни сейчас. Но если это ваш собственный проект, и вы не возражаете против затрат на изменение или плотно интегрированный код, тогда просто взломайте его как один слой.
Это все о будущих затратах. В настоящее время просто программирование, как вы идете, намного дешевле, но не очень хорошо реагирует на изменения. При планировании уровня есть предварительная стоимость, но она может обрабатывать изменения и разрывы реализация целого слоя лучше, чем первый подход.
таким образом, ваше эмпирическое правило определяется тем, кто будет платить за изменение и когда.
Да, это того стоит. То, что вы предлагаете, это взламывать решение вместе. Я не могу сказать, сколько раз это приносило мне боль и страдания. Другая сторона этой монеты-разработчики astronaught, которые перестроили свои решения. Ты тоже хочешь избежать этого.
будьте просты, создайте свои три слоя, я предлагаю вам попробовать LINQ to SQL, это делает построение DAL оснасткой, а затем вы можете сосредоточиться на создании тонкого пользовательского интерфейса и BLL, который будет обрабатывать тяжелый подъем. Это не займет у вас гораздо больше времени, чтобы сделать это, и это позволит для модульного тестирования позже.
есть порог или какое-то правило правило, где вы должны использовать n-уровень?
Не тот, о котором я знаю, но я выброшу это: если есть шанс, что это веб-приложение может расти (или изменять бэкэнды), и/или кто-то еще может в конечном итоге поддерживать его, я бы подумал о подходе n-уровня.
просто держите это возможным. Это, вероятно, излишне сейчас, но не пишите себя в ситуации, когда это невозможно. Рефакторинг в больших масштабах займет у вас больше времени, чем его восстановление с нуля (и, вероятно, будет именно так, восстановление с нуля).
последний проект, над которым я работал (пришел поздно), был написан таким образом, что разбить ярусы было практически невозможно. Логика данных переплетена с бизнес-логикой, переплетенной с логикой представления. В коротком термин, это было так хорошо, как это когда-либо будет, потому что исправление это заняло бы несколько месяцев.
Это не слишком сложно, чтобы держать все разделены так, как я сказал ранее, просто сохранить это возможно.