81

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 ...


76

Business logic doesn't go into the database If we're talking about multi-tier applications, it seems pretty clear that business logic, the kind of intelligence that runs a particular enterprise, belongs in the Business Logic Layer, not in the Data Access Layer. Databases do a few things really well: They store and retrieve data They establish and enforce ...


67

See How much business logic should the database implement? for previous discussion. In general, everyone wants things done in the layer they control. Because then they control it. Every database vendor wants people to put as much logic into the database as possible. Because that locks you into the database. The reasoning is that if multiple ...


66

ElYusubov's answer mostly nails it, domain logic should go into the model and application logic into the controller. Two clarifications: The term business logic is rather useless here, because it is ambiguous. Business logic is an umbrella term for all logic that business-people care about, separating it from mere technicalities like how to store stuff in ...


32

Your colleagues are conflating architecture with implementation. The idea behind a multi-tiered application is simply that it's broken up into parts that encapsulate certain kinds of processing (storage, business logic, presentation) and communicate with each other using well-defined interfaces. Just as it's possible to successfully do things that resemble ...


27

I'll give you some tips regarding CRUD applications, since I don't have much experience in games or graphically intensive apps: Business logic usually involves rules the owner of the business has learned or decided over years of operation, like for example: "reject any new credit if the client hasn't yet finished paying the last one", or "we don't sell ...


21

You and large parts of the programming world seem to misunderstand what the roles of the MVC parts are. In short, they are: Model = domain logic View = output logic Controller = input logic This means that the model is responsible for the entire business logic: anything that is related to drawing widgets on a screen, driving a printer, outputting data as ...


20

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 ...


20

The following answer is in the context of the CQRS style promoted by the cqrs.nu in which commands arrive directly on the aggregates. In this architectural style the application services are being replaced by an infrastructure component (the CommandDispatcher) that identifies the aggregate, loads it, sends it the command and then persists the aggregate (as a ...


19

If you're feeling weird about it or you're getting push back from others, try using the term "Domain Logic" instead.


19

Stored procedures are powerful enough to let you code a violation of three-tier separation by bringing business logic into the RDBMS layer. However, this is your decision, not an inherent flaw of stored procedures. You can limit your SPs to servicing the needs of your data layer, while keeping your application logic in the application layer of your ...


17

People use the terms "business rule" and "business logic" to refer to the portion of your application that is specific to your application and represents the core behavior of how things are supposed to work as opposed to generic functionality that could be useful in software written for a different client/business/customer base or code that exists to support ...


16

I have done a lot of searching but I am still not able to figure out where exactly should I place this Python file containing all the logic. There are a number of options, depending on what your requirements are: Add the logic to e.g. the Image model. This is a useful option if you need to store per-image meta data in the database, and each model instance (...


16

I am very firmly of the view that when ever possible, business logic should be kept in the software layer and not the database layer. Note, that when ever possible falls far short of always. There are strong arguments for both ways, and as always use engineering good judgement to decide for each project how much weight should be applied to each point before ...


15

I am a strong believer in keeping business logic out of the database as much as possible. However, as my company's performance developer, I appreciate that sometimes it's necessary to achieve good performance. But I think it is necessary far less often than people claim. I dispute your pros and cons. You claim that it centralizes your business logic. On ...


14

Business logic almost always has to run on a server you control, for security reasons. If by "server" you mean "web server", then I agree, it doesn't need to have almost any business logic. But you almost always need an application server with the business logic, whether that's inside a database or a web server or is separate and called by the web server. ...


14

To truly isolate business logic and make it separate from the presentation layer infrastructure, it should be encapsulated by application services. The MVC architecture is a way to implement the presentation layer and it should remain at that scope, delegating all business logic to these application services. Think of view models as adapters between the view ...


12

You are essentially asking for a unit system (no, not unit tests, "unit" as in "physical unit", like meters, volts etc.). In your code Age represents time and Pounds represents mass. This leads to things like unit conversion, base units, precision, etc. There were/are attempts to get such a thing into Java, for example: JSR 108: Units Specification Status:...


11

Though you are describing this as a shared coding session (I can't call it pair programming, as only one person is "driving" - in pair programming, both parties take the keyboard and write code), I would call it gathering acceptance criteria. That is, you are validating business rules (correct calculations and processes) with the business user (though one ...


11

That sounds like an eminently sensible decision to me. MVC is a presentation pattern, therefore business logic and persistence operations have no place in the UI layer of the application. Ideally an MVC model is just the data you are presenting to be rendered by the view. This is not at all necessarily the same as an equivalent domain entity - for instance, ...


11

Not technically impossible, but... Scheduling resources, with the goal of finding the ideal schedule that maximizes the use of time slots. I was on a project once, in my earlier computing days, that had this requirement. I worked on it awhile before I realized that it was NP-hard. Other examples of problems that are not technically impossible, but are ...


10

Finding a suitable model isn't always straight forward. It is one of these things which require more experience than plain knowledge. However, the following simple recipe might help you to get over an initial mental block. It was originially described in this paper by Abbott and is frequently referred to as "Abbott's textual analysis". Write a plain text ...


10

I agree with several others here: it sounds like you need to learn more about how to learn the business domain quickly. Journalists do this a lot. When I was in your position a long time ago, I picked up a couple of textbooks on journalism and reporting. I learned a lot from them. Background reading is important; in this day and age, Google is your friend....


10

I'm mostly with you; your colleague seems to be arguing either for the anemic domain model antipattern or for duplicating the model in a "persistence model" with no obvious benefit (I'm working on a Java project where this was done, and it's a massive maintainability headache, as it means three times the work whenever anything changes in the model). What ...


10

I have worked in 2 different companies that had different vision on the subject. My personal suggestion would be to use Stored Procedures when execution time is important (performance). Since Stored Procedure are compiled, if you have a complex logic to query the data, it's better to keep that on the database itself. Also, it will only send the final data ...


10

I agree with SO's LoztInSpace that this is quite opinionated answer and that everyone can have slightly different definitions. Especially if historical influences are involved. This is how I would define the terms: Business logic is logic, that is created with collaboration and agreement with business experts. If business expert says that "Customer cannot ...


10

Two very important points are missing in your pro-database arguments: performance: database code is executed with direct access to the data, thus avoiding unnecessary transfers (be it across fetching API and mapping schemes on the same machine, or across network for client/server communication) consistency: as several applications may access/update the ...


10

"Service layer" is an architectural term. It refers to a portion of the system that sits somewhere in the middle of a multi-tier architecture, below the user interaction layer but above the data access layer. Business logic can be implemented in the service layer, thereby enforcing business rules. Note however that there are cases where business logic ...


9

Always try to understand the business domain before writing any code. Read a book on it and talk to the users/domain experts until you are confident you truly understand your task. Depending on the business domain, this isn't always easy, especially in the beginning. But as time passes and you gain more experience you'll be able to craft good software for ...


9

There's a middle ground that you need to find. I've seen scary projects where the programmers use the database as nothing more than an overpriced key/value store. I've seen others where the programmers fail to use foreign keys & indices. On the other end of the spectrum, I've seen projects where most if not all of the business logic is implemented in ...


Only top voted, non community-wiki answers of a minimum length are eligible