I've been used to the standard 3 tier approach where you have the UI> module (forms), the Business module (classes and components) and then the> DB module (SPs and tables and views) using VB or VB.net and MS Sql Server.> I'm now on a project where they use Oracle and since Oracle allows more> of a development capability, they've put the business logic in the> packages. What do you think of that? I think I still prefer the 3 tier> approach and keeping the business logic out of the DB. OPINIONS?>

===================­================> This list is hosted by DevelopMentorВ® http://www.develop.­com>

View archives and manage your subscription(s) at

As much business logic as possible should go in the db > whether it be oracle or sql server with middle tier objects > acting as brokers between the db and the interface.

As much business logic as possible should go in the db whether it be> oracle or sql server with middle tier objects acting as brokers> between the db and the interface.

As much business logic as possible should go in the db whether it be > oracle> or sql server with middle tier objects acting as brokers between the db > and> the interface.>

As much business logic as possible should go in the db whether it be> oracle or sql server with middle tier objects acting as brokers> between the db and the interface.

As much business logic as possible should go in the db whether it be> oracle or sql server with middle tier objects acting as brokers> between the db and the interface.

It is perhaps unfortunate that Oracle corporation does not view itself> as being in the RDBMS business. It views itself as being in the> application business (witness their recent acquisitions of various ERP> vendors).>

In a way, I can see their point of view -- what useful, real-world> application doesn't rely on a database somewhere along the line? Might> as well just bake it all together. This approach works better in the> enterprise world than in the shrinkwrap software world (in which desktop> features are paramount). Oracle figured they'd never own the desktop> anyway, so they might as well try to beat Microsoft at what is largely> perceived to be its own game (i.e. world domination). Indeed, Microsoft> is making inroads towards this same territory by allowing SQL Server to> act as a CLR hosting environment. (Kinda reminds me of the Open Data> Server API in which one could write C++ extended stored procedures back> in the early '90s. Ecclesiastes 1:9 anyone?)>

So, you asked for opinions, and I gave one. But the larger question is,> in your environment, does anyone's opinion matter? Are these> Oracle-centric applications already in production processing lots of> transactions? If so, you can preach the gospel of N-tier separation of> duties until you're blue in the face but aught will come of it.>

Owen T. Cunningham> Principal Software Engineer> ZANTAZ, Inc. - Introspect Platform Support> ocunning@zantaz.com­ [office email]> 617-239-6813 [office voice]> 7742493035@vtext.co­m [mobile email]> 774-249-3035 [mobile voice]> "Degeneracy can be fun but it's hard to> keep up as a serious lifetime occupation."> -- Robert M. Pirsig>

-----Original Message-----> From: Unmoderated discussion of advanced .NET topics.> [mailto:ADVANCED-DOTNET@DISCUSS.DEVELOP.COM] On Behalf Of Franklin Gray> Sent: Tuesday, September 13, 2005 12:47 PM> To: ADVANCED-DOTNET@DIS­CUSS.DEVELOP.COM> Subject: [ADVANCED-DOTNET] Business logic>

I've been used to the standard 3 tier approach where you have the UI> module (forms), the Business module (classes and components) and then> the DB module (SPs and tables and views) using VB or VB.net and MS Sql> Server.> I'm now on a project where they use Oracle and since Oracle allows more> of a development capability, they've put the business logic in the> packages. What do you think of that? I think I still prefer the 3 tier> approach and keeping the business logic out of the DB. OPINIONS?>

===================­================> This list is hosted by DevelopMentor(r) http://www.develop.­com>

View archives and manage your subscription(s) at> http://discuss.deve­lop.com>

===================­================> This list is hosted by DevelopMentor(r) http://www.develop.­com>

View archives and manage your subscription(s) at > http://discuss.deve­lop.com>

Fair enough, but there may also be disadvantages to that approach.>

* If business logic is in the database, then the user can't get *any*> kind of business processing done without a round trip to the database.> The database server may become the performance bottleneck, since it's> the layer doing all of the work.>

* This approach also means that all of the business logic would be> written in a SQL language, rather than a higher-level language more> suited to business logic development.>

* This approach also suffers from a design constraint because it assumes> that all of your data comes from one place. If you pull data from> multiple sources -- databases, Web services, XML documents -- then there> is no one *right* place for that business logic.>

Just some things to consider ...>

-------------------­-----------------> Magenic Technologies> Jeff Ferguson> Consulting Manager> -------------------­----------------->

===================­================> This list is hosted by DevelopMentor(r) http://www.develop.­com>

View archives and manage your subscription(s) at > http://discuss.deve­lop.com>

I disagree. Putting more logic in the only tier that won't scale is not the>best idea, IMO. I once worked cleanup on a project where the entire system>melted down because way too much business logic was in the DB and there was>no way to scale it. I favor putting business logic in the middle tier>because it's very inexpensive (relatively) to scale out the middle tier.>Once you max out a database box, your only option is to scale up, which can>get very expensive. Additionally, there is a limit to how far you can scale>up a single machine, so even if you have the cash, you may still not be able>to solve the problem.>

-->Steve Johnson

At 01:12 PM 9/13/2005, Steve Johnson wrote> >On 9/13/05, Alex Smotritsky <alex_smotritsky@ya­hoo.com> wrote:> >>

Isn't one of Oracle's pitches (the validity of which I do not pretend to > know) that you can use an "Oracle grid" consisting of large numbers of > commodity servers in order to "infinitely" scale your database?>

I have no idea of the amount you pay to Oracle to get that capability, or > if it works to scale application logic (that could otherwise be a > bottleneck) in the database tier.>

J. Merrill / Analytical Software Corp>

===================­================> This list is hosted by DevelopMentor(r) http://www.develop.­com>

View archives and manage your subscription(s) at > http://discuss.deve­lop.com>

At 01:12 PM 9/13/2005, Steve Johnson wrote> >On 9/13/05, Alex Smotritsky <alex_smotritsky@ya­hoo.com> wrote:> >>

Isn't one of Oracle's pitches (the validity of which I do not pretend to> know) that you can use an "Oracle grid" consisting of large numbers of> commodity servers in order to "infinitely" scale your database?>

I have no idea of the amount you pay to Oracle to get that capability, or> if it works to scale application logic (that could otherwise be a> bottleneck) in the database tier.>

J. Merrill / Analytical Software Corp>

===================­================> This list is hosted by DevelopMentor(r) http://www.develop.­com>

View archives and manage your subscription(s) at> http://discuss.deve­lop.com>

""No technical or functional requirement, just a> business one. This is the very nature of how business gets done and ends> up> with a myriad of different architectures">

Wouldn't this be an example as to why not to put the BL in the DB? Never> know when somebody is going to say "lets switch".

Database independence is a fallacy.

I'm now on a project where they use Oracle and since Oracle allows> more of a development capability, they've put the business logic in> the packages. What do you think of that?

From: "Shawn Wildermuth" <swildermuth_lists@­ADOGUY.COM>>

+1 to that.