Приложение ASP.Net 2.0 без уровня бизнес-логики?

Question

Является ли "приемлемым" иметь приложение ASP.Net 2.0 без BLL (уровня бизнес-логики) следующим образом?

1. Хранение данных SQL Server и хранимые процедуры
2. Канальный уровень (адаптеры со строго типизированной таблицей) для подключения к сохраненным процессам
3. Страницы ASPX уровня представления с кодом и ObjectDataSource для прямого подключения к DLL

Всегда ли BLL предпочтительнее, даже если бизнес-логика полностью проверяется в коде презентации? Каковы потенциальные недостатки неиспользования BLL?

Answer 1

Это приемлемо, если вы понимаете последствия. Основная причина, по которой у вас есть BLL, - это повторное использование этой логики в другом месте вашего приложения.

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

Answer 2

Это зависит. Если ваша бизнес-логика связана с событиями кликов и загрузками страниц, это НЕ приемлемо.

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

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

Answer 3

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

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

Answer 4

Как и все остальное, он экологичен и зависит от использования системы. Вопрос, который вы должны задать себе:

1. Будет ли это активно развиваться?
2. Будет ли это использоваться в течение многих лет и расширено до
3. Является ли расширение приложения неизвестным и, следовательно, бесконечным

На самом деле все сводится к лени. Сколько времени вы хотите потратить на переработку системы из пользовательского интерфейса? Потому что отсутствие бизнес-уровня означает дублирование правил в вашем пользовательском интерфейсе на многих страницах.

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

Answer 5

Если приложение является общим, то уровень бизнес-логики можно использовать и в других приложениях. Например, я обычно использую классы BLL, связанные с CMS, в других приложениях.