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