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

I must agree with Olumide I feel where the business logic or rules should live depends on the nature
of the logic. For database intesive rules I feel they should reside in the database.
A classic example is a trigger, which may update say about 10 different tables, puting this in a bean
will be messy, whereas if stored within the database you have absolute control over the process.
You can even set a different rollback segement for the entire transaction so that you do not maxout
all your rollback segements. All the bean needs is a reference to the event that calls the trigger.

Try using a different rollback segment for a transaction within a bean.

Now you and I know that changing databases is a major effort, and if they change you would have to convert your
stored procedure from one engine to the other, that I feel is not so bad.

Olumide Emuleomo <olu1_at_rcn.com> wrote in message news:382A9FAB.E5562206_at_rcn.com...
> 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 Fri Nov 12 1999 - 11:39:29 CST