On 23/07/11 12:05, John R Pierce wrote:
On
07/22/11 4:11 PM, Darren Duncan wrote:
Karl Nack wrote:
I've been following a few blogs
(http://database-programmer.blogspot.com/,
http://thehelsinkideclaration.blogspot.com/) that make a very
compelling
argument, in my opinion, to move as much
business/transactional logic as
possible into the database, so that client applications become
little
more than moving data into and out of the database using a
well-defined
API, most commonly (but not necessarily) through the use of
stored
procedures.
I strongly agree with that design philosophy. One principle is
that the buck stops with the database and that regardless of
what the application does, any business logic should be enforced
by the database itself. Another principle is to treat the
database like a code library, where the tables are its internal
variables and its public API is stored procedures. Using stored
procedures means you can interact with the database from your
application in the same way your application interacts with
itself, meaning with parameterized routine calls.
the alternative 'modern' architecture is to implement the business
logic in a webservices engine that sits in front of the database,
and only use stored procedures for things that get significant
performance boost where that is needed to meet your performance
goals.. Only this business logic is allowed to directly query the
operational database. The business logic in this middle tier
still relies on the database server for data integrity and
such. The presentation layer is implemented either in a
conventional client application or in a webserver (not to be
confused with the webservices).... so you have user -> browser
-> webserver/presentation layer -> webservices/business
logic -> database
The main rationale for this sort of design pattern is that large
complex business logic implemented in SQL stored procedures can be
rather difficult to develop and maintain
I
was thinking similar thoughts, but you not only beat me to it,
you
made some good points I had not thought of!
The
only thing I can think of adding: is that it would be good to
lock
down the database so that only the middleware can access it,
everything else accesses the database via the middleware.
Cheers,
Gavin
|