0
votes

I'm new to these concepts and currently trying to understand what business and application logic is in my application that i'm developing using MVC concept.

It seems to me that most of the people agree on the fact that application logic belongs to controller and business logic belongs to model. And that is basically the reason i want to be able to determine what is what, so keep that in mind while reading the question to not miss the point.

Business Logic

One of the approaches i've heard is to consider business logic as more of a thing that can be described by people who have nothing to do with programming and just trying to explain how everything would work. So that would basically involve various data to be displayed and how that data is processed(right?).

So for example designing calculator application "business people" would say that we're going to have two numbers at our input and when user presses "Calculate" button we would perform certain actions with given inputs(for simplicity let's say add them), and output the result into the "Result" label.

Application Logic

Now application logic is more of a thing that developers care about and more of a thing that "business people" tend to omit when describing a project of some kind.

Main Problem and Question

Now here's the main problem if you're using the same approach for determining where is business and where is application logic. Notice that i didn't specified what actually application logic involves. And that is because if you think about it this way it really becomes unclear what application logic may or may not involve since different "business people" may or may not include things of all kinds while describing some app which makes this approach impossible to use practically without some kinds of restrictions.

And my question being, what kinds of restrictions should be applied to this approach for having the ability to properly determine where is application and where is business logic or what approach should be used instead? Also is it really correct to say that controller is for application logic and model is for business or can they share some parts of both and if yes then in which way?

Examples (read this section if question is still unclear for you)

Examples from which obscurity comes are:

  • while describing, "business people" may or may not mention:
    • form validation
    • database interaction
    • really any kind of data manipulation that should bother developer but mensioned by non-developers because they realize it is needed for system to function properly

Let's come back to out calculator application. Description given by non-developers could be translated into model in pseudocode like this:

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

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

Then controller would look like this:

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

Let's ignore that business said that on click we should perform calculation and we put that part in controller which is for application logic, because MVC states that controllers must handle these kinds of things, we have different problem anyway - where do we update first and second Number fields? If this approach is used then it simply becomes unclear since different people might and might not mention it, which makes it neither business, nor application logic or both of them which of course doesn't make any sense.

If we imagine business didn't mentioned that we're updating any numbers before calculation(but we realize that it has to be done for any calculation to occur), then we would've determined that it is indeed application logic and would've placed code inside the controller:

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();
 }
}

But if business himself mentioned that we should update the first and the second number before doing the calculation that would've been considered as business logic and accordingly would've been put into the model. At that point we have 2 another options, which are adding the field update directly into calculate method, or creating separate method in our model so we can call it from controller before calling calculate().

Business also may or may not mention if user input should be validated before performing any actions, but it would make calculation impossible if user gives at input two non-digits so you have to implement it and you have to know where to put it.

And let's say one day your clients tell you that they want to store every result of a calculation somewhere and then be able to watch it somehow. That would mean you should send requests to database, but since they didn't exactly mentioned that it has to be database it becomes unclear once again where to put code.

I hope i've made myself clear and you can understand the problem fully to be able to help and/or maybe give your opinion on proper way of designing applications using Model-View-Controller.

1

1 Answers

3
votes

It is much easier to separate business logic from application logic by thinking about if you would want to keep this logic if you were writing a new application on a different platform. If you were porting to a client-side application instead of your web-application, would this still be useful logic?

If it wouldn't be useful in the new context, then the logic is application-specific. If you could use it again, it is business logic.

To take your example of storing calculations, that is business logic. But HOW you store it is more application specific. This is where people end up creating things like DAO objects. To have the application specific method for storing the calculation. This keeps a separation between the fact that you are storing it from the fact that you are storing it in a database (tomorrow it might be a log file, or some web service).