Hot answers tagged

60

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


55

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


40

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


38

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


29

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


23

How much business and systems knowledge should a programmer have ? As much as is needed to solve the problems of your clients. In some cases, it may be minimal. However in many cases, like the one you describe, it is a lot. As @Rachel noted, the better you understand the domain, the more valuable you are to your employer/clients. How does one go ...


22

Expected: None Desired: A lot A programmer who understands the business analytics of a company or industry is much more valuable to that company than an amazing programmer who only knows how to code what he is told. My suggestion would be to learn whatever you can about the industry you are programming for. It will increase your value to employers in ...


19

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


17

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


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

If you mean representing individual business rule checks with exceptions, then I don't think it's a very good idea. Many times you have to report more than one failed condition, and not stop on the first one. On the other hand, I do believe that checking for all rules and then throwing an exception with the summary is a good practice.


14

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


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


11

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


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

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


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

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


10

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


10

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


10

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


9

In the example you've given us I think that raising an exception is a bad idea. If you know that the user is not authorized before they start working and you still allow them to do some function and then smack them with an message AFTER they've already completed the task, that's just a bad design. Using exceptions to enforce business rules is not a good ...


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

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


9

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


8

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

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


7

A few pieces of advice. First, use an analogy - pretend you were implementing this without computers, such as doing it by mail (not E-mail). As you add features, visualize the form customers fill out getting more and more complex. Think about the increased breadth of skills required by staff and the number of staff required to fulfill each function. Talk ...


6

The JavaScript often implements a RESTful service meaning that it is specifying database query. This is where you got it wrong. REST is not CRUD. The resources exposed by REST are not your database records; they're fully managed objects that behave according to your business logic. When the server receives a POST or PUT, it shouldn't just validate ...


6

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



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