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

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

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

8.08.2008 13:04:02
6 ОТВЕТОВ
РЕШЕНИЕ

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

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

8
8.08.2008 13:08:40

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

2
8.08.2008 13:06:16

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

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

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

1
8.08.2008 13:18:38

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

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

0
8.08.2008 13:58:59

Поскольку вам нужна возможность распределять слои по разным физическим уровням (я всегда использую «уровень» для физического и «уровень» для логического), вам следует подумать дважды, прежде чем просто поместить все в один класс, потому что у вас есть основные рефакторинги, чтобы сделать, если или когда вам нужно начать распространять.

1
27.08.2008 09:45:20

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

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

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

0
8.09.2008 17:12:24