87

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


85

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


71

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


68

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


33

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


28

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


24

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


22

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


22

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


20

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


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

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


17

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

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


13

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


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


12

People often hear "micro-service" and think "nano-service", and this can cause some confusion. These are micro-services, so you don't need a separate service for every single entity. Everything you are trying to do should be in the booking and notification services. You don't need the driver service (for any of the activity you described). Getting a list of ...


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


11

You have a couple of perfectly good scenarios already. There are lots of other reasons too. EF is really good at CRUD and at pretty straight forward reporting. Sometimes, though, EF is not the perfect tool. Some other reasons (scenarios) to consider using stored procedures in combination with Entity Framework would include: You have complex units of ...


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

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

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


9

If your business logic involves set operations, most likely a good place for it is in the database because database systems are really good at performing set operations. http://en.wikipedia.org/wiki/Set_operations_(SQL) If the business logic involves some sort of calculation it probably belongs outside of the database/store procedure since databases are ...


9

Your primary difficulties I feel are that you have a mismatch between a very linear and custom workflow in an older application that do not coincide with the user interaction workflows that are common on the web. Web applications that interact with a server application that contain the business logic communicate in a Request/Response messaging style. The ...


8

For me there is no question to be answered here, you should always strive to separate out your components as much as possible. At a bare minimum, for every new project I create I do the exact following steps: 1) Create a blank visual studio solution 2) Add an MVC project to it 3) Add a class library to it called the Business layer 4) Add a class library to ...


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