Re: Application logic and Business logic

From: Thomas Gagne (tgagne_at_wide-open-west.com)
Date: 03/14/05 

Date: Mon, 14 Mar 2005 12:53:51 -0500

frebe wrote:
>>Interesting design decision. Why did they make it?
>
>
> To have a database-vendor independent application. SQL are very well
> standardized, but stored procedure languages is not.
>
>
>>for performance reasons?
>
>
> Stored procedures provides superior performance compared to java, and
> that fact was know before the project started. The converted java code
> was at least twice as slow as the original stored procedure. But stored
> procedures had to go, because they were tied to a specific database
> vendor (Informix).
I reread the paper I referenced and noticed the quote at the top.
Specifically the sentence: "Middleware will allow banks to separate
business rules from access technologies that are particular to a
delivery channel and permit banks to efficiently keep pace with rapidly
changing programming languages."

For the systems I've written it highly unlikely the back-end database
will change. It is far more likely the client application languages
will change. For all this Java code that's been written wouldn't it
have been nice if all the code developed for C clients was immediately
(or easily and inexpensively) usable by Java (isn't that what reuse is
about?)

If the schema has infected the client then the code the client uses for
interacting with the database isn't reusable across multiple languages.
  Two solutions for this is to limit clients' knowledge of the database
through a well-defined API (procedures) or to create a language
independent business-logic-tier.

The result of both approaches is more reusable (and reused) code.
Separation of the clients from the DB is not an ends to itself. Reuse,
ease of maintenance, and ease of adding new features is the desired affect.

To the extent stored procedures aren't compatible with all DB vendors is
a distant consideration. In the extreme one might swap-out Oracle for
Sybase, or Sybase for DB2, procedures are more easily rewritten with
predictable and estimable impact to the client applications (fewer the
better) than SQL.

Regardless, the design of the business-logic engine (a transaction
server) had the greatest impact (along with the ability to multiplex
transactions through multiple TP servers) had the greatest performance
impact.

Best of luck in your project!

Relevant Pages

  • Re: Recordsource only available to Administrator on clients
    ... Do your users have the right to access this second database? ... On the SBS machine as well as the clients, ... to temporarily set a client user's privileges from, ... parameterized stored procedure, ...
    (microsoft.public.access.adp.sqlserver)
  • Re: Recordsource only available to Administrator on clients
    ... if in the ADP all database items appear ... are you able to double-click and execute the uspPT stored procedure from ... Server instance is readily connected via SSMSE (Server type: Database ... to temporarily set a client user's privileges from, ...
    (microsoft.public.access.adp.sqlserver)
  • Re: How to handle concurrency issue with better performance?
    ... Would you put the timestamp check in the stored procedure on the server ... that have been modified since they were pulled from the database. ... select command). ... client) downgrade very much in using such ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Recordsource only available to Administrator on clients
    ... On the SBS machine as well as the clients, ... Server instance is readily connected via SSMSE (Server type: Database ... to temporarily set a client user's privileges from, ... parameterized stored procedure, ...
    (microsoft.public.access.adp.sqlserver)
  • Theoy When Updating Linked Records
    ... to update all the records that they entered that day into a database ... but the server database should contain all of them. ... the server that it was on the client. ... and languages don't play nice with recordset appends. ...
    (comp.databases)