Блог

Главная - Вопросы по программированию - Почему мы не должны внедрять бизнес-логику на уровне пользовательского интерфейса?

Почему мы не должны внедрять бизнес-логику на уровне пользовательского интерфейса?

#model-view-controller #design-patterns

#model-view-controller #шаблоны проектирования

Вопрос:

Хм, единственное, о чем я могу думать, это то, что это дает меньшее повторное использование.Сложнее отличить код от логики пользовательского интерфейса. Исходя из архитектуры MVC, мы не должны использовать логику домена на уровне пользовательского интерфейса?

Ответ №1:

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

Ответ №2:

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

Смешивание их вместе только затрудняет применение изменений и приводит к возникновению ошибок.

Ответ №3:

Разделение проблем имеет несколько важных преимуществ:

  1. Легче понять различные функции, если они физически разделены
  2. Проще заменить модули, которые слабо подключены к системе
  3. Легче модифицировать код, если вам нужно думать только на одном уровне абстракции одновременно.

Здесь особенно актуален номер 2: отделение бизнес-логики от пользовательского интерфейса означает, что у вас может быть несколько пользовательских интерфейсов — веб, настольный компьютер, мобильный — для одного и того же серверного интерфейса.

Ответ №4:

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

Ответ №5:

Предположим, что вы создали большое веб-приложение и поместили его в режим просмотра всей бизнес-логики (BL). Однажды ваш клиент говорит, что нужно изменить приложение и перейти к приложению Desctop, перенести весь код будет сложно. если вы отделяете BL-код от view, он имеет следующие преимущества: 1. легко тестировать код 2. поддерживать 3. изменять 4. и масштабировать, и вы не нарушаете принцип разделения задач