Определение того, что такое бизнес, а что логика приложения

Я новичок в этих концепциях и в настоящее время пытаюсь понять, что такое бизнес-логика и логика приложения в моем приложении, которое я разрабатываю с использованием концепции MVC.

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

Бизнес-логика

Один из подходов, которые я слышал, - это рассматривать бизнес-логику как нечто большее, что могут описать люди, которые не имеют ничего общего с программированием и просто пытаются объяснить, как все будет работать. Таким образом, это в основном будет включать в себя отображение различных данных и то, как эти данные обрабатываются (верно?).

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

Логика приложения

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

Основная проблема и вопрос

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

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

Примеры (прочтите этот раздел, если вам все еще неясен вопрос)

Примеры того, откуда приходит неизвестность:

  • while describing, "business people" may or may not mention:
    • form validation
    • взаимодействие с базой данных
    • на самом деле любые манипуляции с данными, которые должны беспокоить разработчика, но допускаются не разработчиками, потому что они понимают, что это необходимо для правильной работы системы

Вернемся к нашему калькулятору. Описание, данное не разработчиками, может быть переведено в модель в псевдокоде следующим образом:

Class CalculatorModel extends Model
{
  public int firstNumber;
  public int secondNumber;
  public int result;

  public void calculate()  
  {
    this->result = this->firstNumber + this->secondNumber;
  }
}

Тогда контроллер будет выглядеть так:

Class CalculatorController extends Controller
{
  public void onCalculateButtonClick()
  {
    this->model->calculate();
  }
}

Давайте проигнорируем тот бизнес, который сказал, что при щелчке мыши мы должны выполнить расчет, и мы помещаем эту часть в контроллер, который предназначен для логики приложения, поскольку MVC утверждает, что контроллеры должны обрабатывать такие вещи, у нас все равно есть другая проблема - где мы обновляем first и second Number полей? Если этот подход используется, то он просто становится неясным, поскольку разные люди могут и не могут упоминать об этом, что не делает его ни бизнесом, ни логикой приложения, ни тем и другим, что, конечно, не имеет никакого смысла.

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

Class CalculatorController extends Controller
{
  public void updateNumbers()
  {
    this->model->firstNumber = input1->text;
    this->model->secondNumber = input2->text;
  }

 public void onCalculateButtonClick()
 {
    this->updateNumbers();
    this->model->calculate();
 }
}

Но если бы сам бизнес упомянул, что мы должны обновить первое и второе число перед выполнением расчета, это было бы рассмотрено как бизнес-логика и, соответственно, было бы включено в модель. На этом этапе у нас есть еще 2 варианта, которые добавляют обновление поля непосредственно в метод calculate или создают отдельный метод в нашей модели, чтобы мы могли вызывать его из контроллера перед вызовом calculate().

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

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

Надеюсь, я ясно выразился, и вы можете полностью понять проблему, чтобы иметь возможность помочь и / или, возможно, высказать свое мнение о правильном способе разработки приложений с использованием Model-View-Controller.


person Danil Solodunov    schedule 25.08.2015    source источник


Ответы (1)


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

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

Если взять ваш пример хранения вычислений, это бизнес-логика. Но КАК вы его храните, больше зависит от приложения. Именно здесь люди создают такие вещи, как объекты DAO. Иметь метод сохранения расчетов для конкретного приложения. Это сохраняет разделение между тем фактом, что вы храните его, и тем фактом, что вы храните его в базе данных (завтра это может быть файл журнала или какой-нибудь веб-сервис).

person Rob Conklin    schedule 25.08.2015
comment
Это интересный способ думать об этом, я попытаюсь разработать свое приложение, думая таким образом в течение некоторого времени, и посмотрю, как это пойдет. И класс DAO на самом деле именно то, что у меня есть, поэтому, насколько я понимаю, что вы говорите, вызов DAO считается бизнес-логикой и должен быть помещен в модель, но сам DAO - это отдельная вещь, которая должна быть хоть как логика приложения, но поскольку мы только вызываем DAO из модели, это нормально, правда? Так, например, следующий код будет считаться бизнес-логикой и быть помещен в модель? if(!DAO::tableExists()) DAO::createtable(); - person Danil Solodunov; 26.08.2015
comment
Также, что вы думаете о том, чтобы думать о MVC таким образом? Правильно ли размещать логику приложения полностью внутри контроллера, а бизнес-логику - внутри модели? - person Danil Solodunov; 26.08.2015
comment
Нет, я думаю, что создание таблицы зависит от приложения. Не бизнес-логика. Для запуска этого приложения нужна сантехника. Опять же, если бы вы начали сохранять журналы в веб-сервис, это было бы неуместно, то это логика приложения, а не бизнес-логика. Это своего рода логика, при которой DAO должен вызывать сам себя при начальной загрузке. - person Rob Conklin; 26.08.2015