Business-Logic refers to Controller or Model. Please elaborate

Question

I am confused about what is business logic. I assume that it is written in Controller but then I search it on internet but i found that many person say that it refers to model. I am highly confused. And somee community meembers give me suggestions that my question is same but you are doing mistake. I am confused by the answers in those questions. Someone says model is business logic but I assume that Controller is business logic. So Please understand my doubt.

Answer 1

The controller will be clean and more readable, then your all controller functions will be pure actions.

You can decompose business logic as much as you need within the model(service). Code reusability is better and there is no impact on models and repositories.

Business logic might be used in one or more places, so the model is a good place to written code.

Let's take an example:

First controller:

var getBusinessLogic = utilService.getBusinessLogic();

Second Controller

var getBusinessLogic = utilService.getBusinessLogic();

Module(Service)

this.getBusinessLogic = function () {
  // return businessLogic
}

Answer 2

In the general sense, business logic relates to logic in an application that is determined by the application owner.

Common logic found across many different applications that is necessary for the functioning of an application is not considered business logic. This could include e.g. Create-Read-Update-Delete of entities, network calls, authentication etc.

Business logic is logic that is unique to the owners of a specific application.

As such, business logic can show up in any part of an applications code.

However, some people would argue for e.g. 'thin controllers' and 'thick models'. A thin controller is one which contains little to no business logic and defers heavily to the model for performing the appropriate business logic e.g. during Create, Read, Update, or Delete operations.

In an angular sense it is similar, angular controllers are primarily responsible for preparing model data for the scope, the same way an API controller is responsible for preparing data for API requests, and you could aim to minimise the business logic in controllers.

However, business logic doesn't always fit brilliantly in Models either - what if it the update of one model requires updates to other models? This is why often Model Controller frameworks will provide another option - Services. Services provide a more abstract place to perform business logic that is e.g. not related to a single model.

Overall, one good option is to try to keep your controllers 'thin' and keep business logic in models and/or services.