Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Where should the business logic reside in the beans or in

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

From: Joshua Davis <josh_d_at_magicnet.net>
Date: Fri, 05 Nov 1999 03:29:42 GMT
Message-ID: <382250C6.CDBFFBF6@magicnet.net>


We have been attempting to answer the same types of questions. What we found is that if there is business logic that make sense to reside in the database, then it should reside there. We discovered there are advantages to separating your business logic from your database and placing it in Java if you have a legacy database/application environment that doesn't seemlessly integrate with ORACLE. In addition, if you create your business logic fully in JAVA you won't have a headache if the "web based app" needs to be ported to another database.

Good Luck,

Joshua Davis

Jerome Mrozak wrote:

> 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
>
> A major feature of EJB is to permit abstraction of the logic from
> implementation details. Using stored procedures ties you to a
> particular (singular or set of) DBMS. You aren't forced to be portable,
> and can choose between (portable and slightly slower right here) and
> (fast here and big-budget porting issue for new DBMS). In the spirit of
> Java, though, I'd encourage portability.
>
> In your case, calling different stored procedures from a bean seems to
> be an inferior combination of (single stored procedure that calls other
> procedures) and (all SQL in the bean).
>
> --
> Jerome Mrozak
> - Sun Certified Java Developer & Programmer -- goose_at_enteract.com -
Received on Thu Nov 04 1999 - 21:29:42 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US