I kind of get what it means, but not enough to explain it by myself. Is a key concept when talking about the MVC pattern and it's giving me problems to explain that concept too.

  • 4
    "Business Logic" is a very lame term, because it presupposes that we are all doing nothing but business applications. Tell that to a games programmer, they will frown. I prefer "Application Logic" or "Domain Logic". (Of course, in games it is called "Game Logic".) – Mike Nakis Dec 6 '15 at 21:49
  • 1
    @MikeNakis: Are you telling us that game developers are not in the business of writing games? "Business logic" doesn't mean papers and paycheques, it means the logic of the business that you are in. – Eric Lippert Dec 7 '15 at 5:23
  • 1
    @MikeNakis: The word business also have a broader sense of an immediate task or objective : mission, a particular field of endeavor merriam-webster.com/dictionary/business That said, domain logic might be a less loaded term. – JacquesB Dec 7 '15 at 9:18
  • @EricLippert Aha, I see. I admit it makes a bit more sense now. – Mike Nakis Dec 7 '15 at 9:34

In layman's terms:

Imagine this: in the eighties you wrote a piece of software that allowed people to track their personal finance. That software showed reports in text-only mode in a phosphor screen and saved data to diskette files.

Later in the nineties you rewrote the program to work in Windows graphical environment. You had to make cool windows and dialog boxes and accept mouse input, and save the info into MS Access files. That part that does the financial tracking didn't change a lot, you had to re-write in another language, added some adjustments but the most part didn't change a lot.

Then in the 2010's you rewrote the app to be web based, and data were stored in a MySQL database in some cloud. The financial tracking part of the software didn't change in a dramatic way, it improved, maybe you had to translate it to a more modern dialect but taking good care not to break it. It continues to be based on the things your grandpa taught you before computers were mainstream. Your grandpa was an accountant and he knew how to do all the financial stuff with just pen, paper and a desktop calculator. The knowledge of your grandpa is what you put in your software to begin with in the form of rules, legal ordinances, workflow, algorithms, conditions etc.

Well, the part of the software that changed the least in all that evolution is what we call business logic. The part your grandpa knew how to do manually. We used to call it know how, business rules, etc. Now, in the software world, the part of the source code of a program that does the calculations and applies conditions and transformations if called business logic.

Business logic is presentation-agnostic and persistent-agnostic. Meaning it doesn't care whether a report is shown in an iPhone screen or printed to a dot matrix printer, and it also doesn't care whether the data is saved to files, to the cloud or has to be typed every time by an operator.

| improve this answer | |

"Business Logic"* is the part of your application which deals exclusively with the rules, processes, and algorithms that are necessary in order to solve the problem at hand (in other words, for the application to fulfill its raison d'être) without any concern whatsoever to peripheral concerns such as precisely how to receive input from the user, precisely how to present stuff to the user, precisely how to persist stuff to the database, and in general, without any concern to the nitty-gritty technical details of how to convince the machine to perform the low-level operations necessary in order to solve the problem.

* I prefer the terms "Application Logic" or "Domain Logic".

| improve this answer | |

The business logic is the part of the software where you implement algorithms to solve the problem that you're trying to solve with your program. It's the part where the real calculations happen. The other parts are for database access, exporting to different file formats, visual representations.

| improve this answer | |

In MVC, the Controllers are very application specific. So the Business Logic should stand inside the MODEL for reuse.

MVC could also mean that the "Controllers" encapsulate the business logic for the "Views". Views in this sense are skinny, Models can be skinny or fat (depending on the validations and data-specific calculations needed), and Controllers handle the functionality container by the Views (the when/where/how).

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.