Зачем нужен бизнес-логики?

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

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

11
asp.net c# design

5 ответов

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

  1. Он сохраняет всю вашу бизнес-логику локализованной и в одном месте. В результате будущие изменения будут намного проще.

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

  3. Он держит ваш пользовательский интерфейс намного тоньше.

Читайте также: принцип единой ответственности (в двух словах, ваши классы пользовательского интерфейса должны делать вещи пользовательского интерфейса, а не бизнес-логику).

17

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

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

SoC и SRP упрощает и упрощает:

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

вот аналогия (да, она упрощена): автомобиль частично управляется с помощью рулевого колеса и педали газа. Рулевое колесо управляет направлением автомобиля, а педаль газа управляет скоростью автомобиля.

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

держать 2 заботы (скорость и направление) отдельно делает его более легким и более безопасным управлять.

см. также

10

разделение:

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

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

8

задайте себе вопрос: есть бизнес-логика в этом приложении?

вернее: Ты

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

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

во втором случае вы, безусловно, должны создать некоторые бизнес-объекты и попытаться распутать их из базы данных и вашего пользовательского интерфейса (высокая когезия, низкая связь, инкапсуляция с сокрытием информации). Сделайте свою бизнес-логику доступной для независимого подразделения тестирование и спросите себя, можно ли быстро перенести его из Oracle в базу данных SQL Server или из пользовательского интерфейса winforms в приложение silverlight с использованием той же бизнес-логики.

5

Что произойдет, если в будущем вы захотите использовать ту же самую проверку/бизнес-логику вне этого конкретного пользовательского интерфейса? может быть, это приложение должно будет предоставить веб-сервис, который включает в себя ту же логику? или вы можете работать с клиентским / серверным приложением, автономным приложением windows и asp.net веб-приложение, все из которых используют одну и ту же бизнес - логику и логику проверки-в этом случае разделение проблем сэкономит вам много избыточного кода и много возможностей для ошибки (тем самым сокращая время отладки).

4