Re: Where should the business logic reside in the beans or in

The problem with putting all your business logic in Javabeans is that a) Database portability is a myth. If you change database servers,

   you will have to port your code. (You will also have to hire new    Database Administrators)
   Writing your SQL code with portability paramount in your mind is coding    to the least common denominator and sacrificing    *PERFORMANCE*. You also sacrifice performance because you tend to make more    trips to the database if the logic resides solely in your app server! b) Integrity. How can you be assured that the database cannot be changed 'behind' the back of

   your application server?

The truth is, some business logic belongs in the database and some belong in your app server.
The rule of thumb is that "the more primitive the logic, the greater the likelihood that it belongs in the db"

--Olu E.

Evan Sparago wrote:
>
> If you put all of your business logic in your stored procs, then you do
> three things which I would claim are dangerous. To whit;
>
> 1) you marry yourself to that database. One likes to think that stored
> procs are migratable, but the sad truth is that they are not always
> compatible. A proc on SYBASE may, or may not work on ORACLE. Also,
> even though you may think you will never migrate to another db, the
> truth is that more often than not, the db changes.
>
> 2) you limit all of your processing to that database. You might someday
> consider spreading your db over some enterprise. It may not always be
> true that all of your data will therefor reside entirely on one db. If
> all of your logic is in stored procs, your in trouble.
>
> 3) procs are procedural and not object oriented. OO is better.
>
> I would always (can I stress the word 'always') put the business logic
> in the bean. They should be stable (I don't see JAVA being replaced
> anytime soon). They can interact with multiple database instances, and
> they leave the brains where it belongs, on the web or application
> server. Until db's allow for object design (and ORACLE 8.x appears
> ready) it is folly to move your logic anywhere other than the bean
>
> Of course that is just my opinion, I could be wrong.
>
> Evan
>
> Olumide Emuleomo wrote:
> >
> > A stored procedure seems logical, as long as both operations are done within a
> > transaction!
> >
> > --Olu E.
> >
> > Seigmund Akinwande Johnson wrote:
> > >
> > > I am currently deploying a web based app which requires some business logic
> > > and database, I would like to know how to determine where the business logic
> > > resides.
> > >
> > > Example
> > >
> > > If a customer withdraws more that X amount of dollars from an account insert
> > > a record which contains
> > > the customer id and the amount, into another table, this requires calls to
> > > the database.
> > >
> > > Now my question is should I write a stored procedure to do everything in
> > > one call
> > > ( hence business logic is in the database) or use Java objects in a
> > > middleware which will call the stored procedures separately, so the business
> > > logic is in the stored procedure.
> > >
> > > I am completely database oriented and feel strongly about making this in
> > > one network trip instead of
> > > having the business logic in the middleware and making 2 separate calls.
> > >
> > > --
> > > Developer
> > > BSDIS
> > > 773-834-2652
Received on Thu Nov 11 1999 - 04:51:23 CST