53

I have created a simple MVC Java application that adds records through data forms to a database.

My app collects data, it also validates it and stores it. This is because the data is being sourced online from different users. the data is mostly numeric in nature.

Now on the numeric data being stored into database (SQL server), I want my app to perform computations and display the results. The user is not interested in how computations are done so they must be encapsulated. The user must only be able to view the simple computed data (for example, A column data minus B Column data divided by C column data). I know how to write stored procedures for same but I want a three-tier app.

I want the data that I put into the database as a record, worked upon by performing calculations on it. The original data should remain unaffected, while the new data, post-calculations, must be stored as a new entity record into the database.

Where should I write the code for this background calculation? As it is the rules and business logic, should I put it in new JavaBeans files?

Yusubov
  • 21,328
  • 6
  • 45
  • 71
BriskLabs Pakistan
  • 631
  • 1
  • 6
  • 4
  • possible duplicate of [Staying OO and Testable while working with a database](http://programmers.stackexchange.com/questions/42792/staying-oo-and-testable-while-working-with-a-database) – gnat Apr 13 '15 at 09:50
  • Business logic is alias to a guy in your team / department who you ask how to do / operate on a model. That's why, the Business logic can be stored in a separated class named Business logic. The same applies to Presentation Logic which is a synonym to a designer guy who answer your questions about how to format or display UI components. There can be also a Developer Logic ( questions which you ask and answer by your self or ask your colleagues) which represents a knowledge about how to create and connect a program components together. – Blazej SLEBODA Oct 04 '20 at 13:06

3 Answers3

95

The business logic should be placed in the model, and we should be aiming for fat models and skinny controllers.

As a start point, we should start from the controller logic. For example: on update, your controller should direct your code to the method/service that delivers your changes to the model.

In the model, we may easily create helper/service classes where the application business rules or calculations can be validated.

A conceptual summary

  • The controller is for application logic. The logic which is specific to how your application wants to interact with the "domain of knowledge" it belongs.

  • The model is for logic that is independent of the application. This logic should be valid in all possible applications of the "domain of knowledge" it belongs.

  • Thus, it is logical to place all business rules in the model.

Community
  • 1
Yusubov
  • 21,328
  • 6
  • 45
  • 71
  • 3
    nice clear and concise answer.. – hanzolo May 15 '13 at 22:46
  • @Yusubov, please could you explain me the difference between the application logic and the business logic – Mo Haidar Aug 16 '15 at 20:57
  • 1
    @Moh, In short these are buzz words to help describe tiers of technology in an application. Business logic is basically rules of the system according to functional specifications. For example Object A of type B must have attributed C and D, but not E. Application Logic is more of a technical specification, like using Java servlets and OJB to persist to an Oracle database. – Yusubov Sep 17 '15 at 12:10
  • Would you please elaborate on these words: `The most common mistakes are to implement application logic operations inside the controller or the view(presentation) layer.` [ http://php-html.net/tutorials/model-view-controller-in-php/ ] – revo Oct 13 '15 at 10:59
  • 1
    If i understood correct, the mentioned article refers to 'application logic' as a 'business logic'. Thus, anything that refers to the business logic should not be placed in controller or the view. – Yusubov Oct 30 '15 at 21:48
  • "fat models" does not mean "fat classes", I sincerely hope? – Olle Härstedt Jan 22 '20 at 15:09
  • @Yusubov Some sites describe the model as the database. How can the model be a database and at the same time the container of the business logic? – pentanol Aug 12 '21 at 12:44
25

As always, it depends on the complexity of the project.

In trivial applications, where the domain model complexity is relatively small, you can put the logic in the models and call it a day.

However, for non trivial applications with complex models and lots of business rules, it's better to separate things a little bit more.

If you put the business logic that involves more than one model in a model, you are introducing a tight coupling between those models. As applications continues to grow, these models tends to turn into god models, knowing too much. And this will quickly turns into a big mess that is hard to test and maintain. So in that case, it is beneficial to put the logic in a separate layer.

When deciding about abstraction, always take your app complexity and purposes into account, and avoid over-engineering. For trivial/small applications, introducing more layers than it needs increases complexity instead of reducing it.

Robert Martin(Uncle Bob) has a good blog post on this subject: The Clean Architecture.

Hakan Deryal
  • 1,403
  • 10
  • 13
  • the question was specific for MVC. business logic should always be in the model. The controller is just an adapter. – jgauffin Sep 20 '12 at 05:49
  • 12
    MVC is one of the most overloaded terms in the industry. I don't want to get in the quirks of this term, as it warrants a book. Just, using MVC doesn't imply that you must put every logic in the models. – Hakan Deryal Sep 20 '12 at 05:58
  • 2
    From the definition by Steve Burbeck (Smalltalk team): `The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate`. That's an adapter definition. – jgauffin Sep 20 '12 at 06:11
  • 6
    If you put all the logic in the model, you will end up with thousands of lines of unmaintainable mess. Been there. It's not a sin to have utility classes and a service layer. – asthasr Sep 20 '12 at 10:49
  • 1
    I think what jgauffin was getting at is that the question is specific for MVC. If we agree to view the system from the MVC perspective and only the MVC perspective, then yes, all of the business logic belongs in the "model", but the "model" may _encompass_ multiple classes and layers, including "utility classes" and "a service layer". To put it another way, we wouldn't say the service layer is a part of the controller or view, therefore the best fit is the model. – DavidS May 29 '15 at 20:31
6

Putting the business logic inside the model might sound the best way to go. The controller receives a call from the remote web app. The controller on the MVC web service takes the call and redirects the execution to a method in BL. Now, Business Logic can be contained in the 'Model', but can also be positioned in some other folder, say, 'Business Logic'. So there's no hard-and-fast rule on where the business logic is going to be.

I've been using a web service built on MVC 3.0 and the container of business logic is the MVC MODEL.

MontyPython
  • 161
  • 2
  • I agree. You get a much more flexible application when your model is simply a data structure acted upon by other business logic classes. As a simple example, I think that is a big failure of ASP.NET's approach to validation by using attributes. If I annotate a Person's FirstName property with the Required attribute, what happens if I create an admin view where FirstName should not be required? A business logic layer should consume the model and determine the appropriate actions for it. – xr280xr May 12 '15 at 18:31