Есть ли какие-либо негативные причины для использования N-уровневого решения?

Question

Я довольно новичок в своей компании (2 недели), и мы запускаем новую платформу для нашей системы, используя .NET 3.5 Team Foundation от DotNetNuke.Наш "архитектор" предлагает нам использовать проект одного класса.Конечно, я предпочитаю "трехуровневую" архитектуру (бизнес, данные, проекты веб-класса).

Есть ли какие-либо недостатки в использовании этой архитектуры?Плюсами было бы отделение кода от данных, удаление объектов класса от вашего кода и т.д.

Answer 1

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

Все зависит от того, что соответствует размеру проекта, ожидаемому сроку реализации конечного проекта и бюджету!Иногда, несмотря на то, что делать что-то "правильно" привлекательно, правильным коммерческим решением может быть создание чего-то более "легкого"!

Answer 2

неопытной команде, как правило, требуется больше времени для создания 3-уровневой системы.Больше кода, а значит, больше ошибок.Хотя я просто играю роль адвоката дьявола.

Answer 3

Я бы упорно настаивал на N-уровневом подходе, даже если это небольшой проект.Если вы используете инструмент ORM, такой как codesmith + nettiers, вы сможете быстро настраивать проекты и разрабатывать код, который быстро решает ваши бизнес-задачи.

Меня убивает, когда вы начинаете новый проект и проводите дни, сидя за вращающимися колесами и рассуждая о том, как должна быть спроектирована "архитектура".Вы хотите тратить время на решение бизнес-задач, а не на решение проблем, которые другие люди решили за вас.Использование ORM (на самом деле не имеет значения, какого именно, просто выберите один и придерживайтесь его) для получения начальной отдачи поможет вам сосредоточиться на целях проекта и не отвлекать вас попытками решить проблемы "архитектуры".

Если, в конце концов, архитектор захочет использовать подход "один проект", нет причин, по которым вы не можете создать папку app_code с папками BLL и DAL для разделения кода на данный момент, что поможет вам позже перейти к N-уровневому решению.

Answer 4

Потому что ты хочешь, чтобы способность что касается возможности распределять слои по разным физическим уровням (я всегда использую "tier" для физического и "layer" для логического), вам следует дважды подумать, прежде чем просто помещать все в один класс, потому что вам предстоит провести серьезный рефакторинг, если или когда вам действительно нужно начать распространение.

Answer 5

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

Кроме того, даже если ваша система на данный момент невелика, вы можете захотеть добавить в нее дополнительные функции позже, не переходя на N-уровневый уровень мог бы это своего рода технический долг с вашей стороны, поэтому вы должны быть осторожны.

Answer 6

Единственным недостатком является сложность, но на самом деле насколько сложно добавить некоторые объекты домена и привязать их к списку в отличие от использования набора данных.Вам даже не нужно создавать три отдельных проекта, вы можете просто создать 3 отдельные папки в веб-приложении и присвоить каждой из них пространство имен, например, YourCompany.YourApp.Domain, YourCompany.YourApp.Data и т.д.

Большим преимуществом является наличие более гибкого решения.Если вы начнете писать свое приложение как приложение, ориентированное на данные, строго связывая страницы веб-форм с наборами данных, то в конечном итоге вам придется выполнять гораздо больше работы, переходя к более предметно-ориентированной модели по мере усложнения вашей бизнес-логики.

Возможно, в краткосрочной перспективе вы сосредоточитесь на простом решении, создав очень простые объекты домена и заполнив их из наборов данных, затем вы сможете добавлять к ним бизнес-логику по мере необходимости и создавать более сложный ORM по мере необходимости или использовать nhibernate.