Hot answers tagged

62

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


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


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


6

I will focus on the two core problems described in your question: Soon there are like hundreds of configurable options, and even naming them becomes a nightmare, let alone managing them, changing them, tracking them in code The naming problem can be solved by organizing them in hierarchies. For example, look at the thousands of options you will find in ...


6

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


5

A business process is a series of actions that are executed by a business to perform a particular task. For example, when a customer places an order with a company that company goes through a process that might involve checking stock in the warehouse and getting the item from the warehouse, packaging the item, sending it and finally invoicing it. A business ...


5

Nested conditions along the lines of ((foo or bar) and baz) are hard to comprehend, and I understand that you want to avoid them. Indeed, you can avoid the logical operators and, or and not if you allow conditionals to be nested: if (foo and bar) then action is equivalent to if (foo) then if (bar) then action if (foo or bar) then action is ...


4

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


4

There is a gross misconception somewhere. I think it is near this idea. In Spring+JSF application all the business logic was encoded in special layer - Spring entities and services. In Spring+REST+AngluarJS this should be different. I don't want to rewrite (move) business logic from Spring/Java to AngularJS/JavasScript but obviously I am required to ...


4

Besides all the facts that have been already pointed out, also remember that having business logic in your code rather that the database eventually turns out to be cheaper. When looking for a developer for an application written in PHP and using MySQL as a database, should your business logic be stored in the database, a simple PHP programmer is not enough, ...


3

The "correct" way is the one that most effectively satisfies your application's non-functional requirements for maintainability, performance, etc. What you need is a Business Logic Layer or Service Layer. These layers translates CRUD methods into actual business operations. Yes, you'll have more classes, but those classes are going to be better organized ...


3

I read on the internet that I should do as less as possible in the controller. What do they mean? They mean the Controller is a part of the UI. And you should do only UI-related things inside it. If you need to so something with your model data, you place those actions into another layer (bussiness layer, logic layer, call it whatever you like) and call ...


2

The whole point of MVVM is to abstract as much logic as possible away from the View, the surface that the user sees. If you're using CodeBehind to implement business logic, you're probably not practicing MVVM. This has several benefits: It makes the code more testable. UI is difficult to test, especially UI that has CodeBehind. If the business logic is ...


2

There are several options you can consider to tackle this problem at the design level. Pattern-wise, you might want to get yourself a refresher about, including, albeit not limited to: The abstract factory design pattern http://www.dofactory.com/net/abstract-factory-design-pattern which could maybe used in combination with: The strategy design pattern ...


2

The way you describe it, I would put the code to update the balance in a separate UpdateBalanceService-class. Then create a new class 'RefreshBalanceService' that contains both the UpdateBalanceService and a ProcessNewFeesService. The UpdateBalanceService-class would then call both services and perform the necessary actions. It is then a matter of ...


2

The following query: SELECT a.user_id AS a_user_id, b.user_id AS b.user_id, a.question_id, a.answer FROM answers AS a INNER JOIN answers AS b ON a.question_id = b.question_id AND a.answer = b.answer; WHERE a.user_id <> b.user_id; will give you a long, long table with all identical answers by all users. You ...


2

Possibly, but if these contact records are going to be entered by employees, it is perfectly possible that you could have a difference in address/name/phone number styles that would make this difficult. E.g. for address: 1 High Street 1, High Street 1 High St This applies across columns too: Joe Smith|1 High Street Jo Smith|1 High St I'd also ...


2

The strategy of using shared libraries to solve logic duplication as @Tibo discussed becomes more difficult as client and server platforms diverge. Convenient solutions to avoid complexity or repetition, like sharing a language across a stack or between a client and a server, are ideal at the beginning of a project. Though, in some circumstances, there are ...


2

You could create a table that stores courses that can be taken with each other: CourseCombination (id, course1id, course2id). Then you could create a table that stores a single value representing the time frame a student can take any given combination of courses: CourseCombinationTimeFrame. Then in your application create a place for the system ...


2

Main thing is once the product is delivered, and if there is any need of changing the business logic then they want to be able to that themselves That's potentially a huge issue. You need to be able to scope this, and determine what they're likely to want to change e.g. switch between a couple of behaviours? Then provide a config/flag to provide that ...


2

If someone is going to change a method which is reused somewhere in your codebase, he should be responsible for making an impact analysis before. So a dev who starts to implement a change in DoSomething should check beforehand from where this method is called. So lets assume you already found out DoThisSomethingAndMore won't work any more correctly when ...


1

This approach is pretty common in workflow applications. Business logic may not be in database tables but it can often be dynamically loaded by the system and designed by domain experts. Workflow foundation may be worth a look.


1

Previous answers give great reasons to why it's easier/better to put logic in application code vs in a database. One exception I'd like to highlight is when using a big data database/tech stack. In this case, many of the disadvantages go away: You can write unit tests since it's actual code you wrote that sits in the database. You can debug, albeit through ...


1

What you want to do is called a three-way merge. Basically, you take the original before the branch, and the end result of the two branches. You take the differences between both branches and the original, and merge those diffs together. How do you merge the diffs? That's the tricky part, but here are several projects which implement the algorithm for ...


1

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


1

People who work in software product lines frequently wrestle with the same problems - how to write software that can vary depending on the deployment environment. There are several methods that have been identified to manage variability - build-time configuration, plug-in architecture models, run-time configuration of properties, configuration files, ...


1

You can associate vouchers with orders as Muhammad suggested and use ajax to check availability. Count all vouchers for open and paid orders. Don't count vouchers for cancelled orders. This way someone might not be able to use a voucher, but later someone else might. If that first someone complains about that, make sure, you have one extra stock item that ...


1

As others have pointed out, these terms do not have one universally accepted meaning. I will describe the definitions I have encountered more often, i.e. in several projects with different companies. The business logic defines a normalized, general-purpose model of the business domain for which an application is written, e.g. Classes like Customer, Order, ...


1

Every system or application is going to have its own definitions of what is business logic and what is application logic. It will either be explicit or implicit. In my experience data driven applications (e.g. DBs etc.) tend to have a more formal definition of what the business logic is. The application logic tends to focus on getting information from ...


1

Na, they're just different terms for the same thing - the "middle tier" of program code that does the things you want your program to perform. Like many things in software, there are no hard-and-fast terminology for pieces of a system, as there are no single formal definitions for building systems. So sometimes people will call it business logic, others ...



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