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

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

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

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

7.08.2008 02:41:24
5 ОТВЕТОВ

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

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

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

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

1
7.08.2008 02:46:16

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

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

4
7.08.2008 02:48:48

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

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

1
7.08.2008 02:49:53

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

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

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

1
31.08.2008 07:28:39

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

0
23.10.2009 07:59:29