Where Does Business Logic Belong?
February 25, 2013 in ROFX
The question of where business logic belongs is as old as database application development. Early on, with primitive client server development, the business logic existed in the client and the database existed only to persist the data.
The advantage of this approach is that it makes the client responsive for input validation, and simplifies the degree of coupling between the client and server. The disadvantage is that if a different client connects to the database, the business logic is no longer enforced. This compromises the integrity of the database. There are other disadvantages to client server development – to learn more, read the white paper on “Why Multi-Tier”.
With the introduction of Multi-Tier database application development, the business logic moved to a Middle-Tier.
This has the immediate advantage of keeping the database secure no mater which client connects, while also simplifying client development. The disadvantage is that the client has to make a round trip to the server to validate user input – a major hit in the user experience department.
What I’ve seen some developers do is duplicate the input validation business logic from the middle-tier into the client. This speeds up input validation, but increases the complexity of client development, and requires that any business logic updates be made in two places – duplication of code is rarely the right answer.
Thankfully Data Abstract has a solution for this thanks to the new Business Rule Scripting support. Not only does it allow you to easily define your server side business logic in JavaScript, but also, select scripts are shared from the server to the client for fast and convenient validation and the best possible user experience.
This has the advantage of running the validation logic twice – once on the client for fast response, and then again on the middle-tier to protect the database. This is the best of both worlds – you keep your database secure and your client application responsive with no duplication of effort or code to keep synchronized. Data Abstract takes care of all that for you.
Additionally, Data Abstract’s schema technology keeps the client completely decoupled from the database. This keeps the database easier to maintain, and allows your application to easily migrate to a new database when your project requires it.
Both schemas and business rules scripting are supported in all editions of Data Abstract: .NET, Java, Delphi, Xcode and JavaScript. Learn more about Business Rules Scripting on RemObjects TV.
Hur AKDULGER said on February 25, 2013
In fact, one tier is not enough, two tier is good, but 3 tier is best…
Regarding to our requirements, we could put our business logic on any tier.
This kind of usage gives more flexibility to application architects and designers.
Cameron said on February 25, 2013
C/S often increases complexity, takes longer to develop and slows debugging but scales better. Direct access is often faster to code but doesn’t scale as well in larger systems and limits future flexibility. So IMO the answer is “All of the above”. A developer boxing themselves in by requiring XYZ methodology is akin to viewing every problem as a nail with C/S being the hammer. A good developer will assess the environment, project requirements and other non specific issues before deciding on the business logic methodology.