How can I avoid getting notifications to my own posts?
Business logic
Hello Guest
  
  • Login
• Register…
• Start blog
  • Who, Where, When
• What can I do?
• What to Read?
  • Polls
• Avatars
• Interests
  • Cities and Countries
• Random blog
• Users search
  • Search
• Games
• Tests
• QAIX
  • Ñîîáùåñòâà
• Talxy Chat
• Horoscope
• Online
 
Çàðåãèñòðèðóéñÿ!

QAIX > .Net Development > Business logic 23 September 2005 18:08:25

  Recent blog posts: 
  They have birthday today: 
  Forums:   
  Discuss: 
  Recent forum topics: 
  Recent forum comments:
  Moderators:

Business logic

Franklin Gray 23 September 2005 18:08:25
 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 http://discuss.deve­lop.com

Add comment
Alex Smotritsky 13 September 2005 19:52:21 permanent link ]
 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.

-----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 9:47 AM
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. http://www.develop.­com

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

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

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

Add comment
Rob Redeye 13 September 2005 19:57:08 permanent link ]
 IMHO. u should always try to push as much processing as possible down to
the data engine. this is MOST efficient being that the data transfered
between levels is minimized.

Redeye

----- Original Message -----
From: "Franklin Gray" <franklin.w.gray@US­.ABB.COM>
To: <ADVANCED-DOTNET@DI­SCUSS.DEVELOP.COM>
Sent: Tuesday, September 13, 2005 12:46 PM
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® http://www.develop.­com>
View archives and manage your subscription(s) at
http://discuss.deve­lop.com

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

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

Add comment
Owen Cunningham 13 September 2005 19:57:21 permanent link ]
 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 http://www.develop.­com

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

Add comment
Jeff Ferguson 13 September 2005 20:03:38 permanent link ]
 
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.

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 http://www.develop.­com

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

Add comment
Kamen Lilov 13 September 2005 20:09:22 permanent link ]
 My work has taught me rather the opposite of what Alex and Rob are
advocating.

Indeed Oracle PL/SQL is a generation ahead of the clumsy misunderstanding
called TransactSQL. Still, I believe you shouldn't put too much BL into the
database itself.

Examples of good things to put into the DB (and, in turn, PL/SQL packages)
are search functions that construct dynamic SQL and execute it against the
database; insertions/updates/­deletes that need to "atomically" go against a
few DB tables - atomically in the logical sense, not in the sense of
transactions. Relations of any kind are also excellent candidates for the
DB tier.

Your .NET BL tier, on the other hand, should have intimate knowledge of
things like:
1) Allowed values in a NUMBER column (e.g. a certain column must always have>0 value)
2) Interrelationships between columns in a table (e.g. "When USERFLAG is C
or D, VENDORSTATUS should be NULL, otherwise if USERFLAG is X, VENDORSTATUS
should be a positive FK to table ZZ1, and for all other values of USERFLAG
VENDORSTATUS should contain -1)
3) Interrelationships between "objects" residing in different tables - e.g.
a Vendor object (roughly equivalent to a VENDOR record) vs. a Contact object
(a CONTACT record plus 1 or more ADDRESS records, used with VENDOR, CUSTOMER
and so on)

Putting BL in packages, from my opinion, is a leftover from the days where
the database was being called by C/C++ apps (difficult to get BL easily and
effortlessly in those), and Oracle Forms (where everything is PL/SQL
regardless of whether it runs on the DB server or in the Oracle Forms Client
framework)

Regards,
Kamen Lilov
Delera Systems
http://www.delera.c­om

-----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 7: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. http://www.develop.­com

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

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

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

Add comment
Owen Cunningham 13 September 2005 20:09:56 permanent link ]
 Amen brother. Also, what happens if you have to switch RDBMS vendors?
We're in the shrinkwrap software business and have built a lot of
business logic into the SQL Server back-end. More than one prospective
customer has told us "it's Oracle or the highway." Our solution probably
won't be to port all our mounds of T-SQL to PL/SQL and maintain a split
codebase -- instead, we'll probably migrate all the logic into an
RDBMS-agnostic middle tier and use only ANSI-92 SQL interactions through
a generic ODBC endpoint.

-----Original Message-----
From: Unmoderated discussion of advanced .NET topics.
[mailto:ADVANCED-DOTNET@DISCUSS.DEVELOP.COM] On Behalf Of Jeff Ferguson
Sent: Tuesday, September 13, 2005 1:04 PM
To: ADVANCED-DOTNET@DIS­CUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] Business logic
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.

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

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

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

Add comment
Steve Johnson 13 September 2005 20:12:40 permanent link ]
 On 9/13/05, Alex Smotritsky <alex_smotritsky@ya­hoo.com> wrote:>
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.>

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

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

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

Add comment
Ryan Reid 13 September 2005 20:13:33 permanent link ]
 I do agree that the Oracle Corporation is often more than just a little
confusing.

I don't think that you can make the "right" decision when it comes to
architectural decisions like this, especially as it sounds like some of the
decisions have been made. A lot depends on what is written already and what
sort of talent you have sitting around waiting to work on it.

I do think that you are likely to enjoy yourself a bit more writing at least
your complex stuff in Visual Studio (and VB, it sounds like) -- your
environmental options and control are generally better, the debugging
environment is much (IMHO) better, and you may even get some reasonable code
reuse.

-----Original Message-----
From: Unmoderated discussion of advanced .NET topics.
[mailto:ADVANCED-DOTNET@DISCUSS.DEVELOP.COM] On Behalf Of Owen Cunningham
Sent: Tuesday, September 13, 2005 9:57 AM
To: ADVANCED-DOTNET@DIS­CUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] Business logic

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. http://www.develop.­com

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

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

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

Add comment
Kamen Lilov 13 September 2005 20:15:08 permanent link ]
 Owen,
instead, we'll probably migrate all the logic into an RDBMS-agnostic
middle tier and use>> only ANSI-92 SQL interactions through a generic ODBC endpoint.

That won't get you nowhere. Or rather, it will get you to a situation where
your app nearly works, but with terrible performance on each and every
database.

Instead, migrate all the logic into a data tier whose API is RDBMS-agnostic,
and is called by your main application, then write two copies (binary
compatible on an API level, probably using some kind of plug-in-like
architecture) of the data tier - one for SQL Server, one for Oracle, and so
on.

I've also seen people doing it all in one place and #ifdef-ing depending on
the RDBMS, but I suspect this is very error-prone (never been there myself
though)

Regards,
Kamen Lilov
Delera Systems
http://www.delera.c­om/blog/


-----Original Message-----
From: Unmoderated discussion of advanced .NET topics.
[mailto:ADVANCED-DOTNET@DISCUSS.DEVELOP.COM] On Behalf Of Jeff Ferguson
Sent: Tuesday, September 13, 2005 1:04 PM
To: ADVANCED-DOTNET@DIS­CUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] Business logic
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.

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

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

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

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

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

Add comment
Owen Cunningham 13 September 2005 20:20:51 permanent link ]
 Potato, potahto. My point was just that we won't use the database to do
anything except be a database, and anything more semantically
complicated than that will go in an external tier that knows how to
route between different data sources efficiently. You make a good point
about performance concerns, though.

I just added your blog to my RSS reader.

-----Original Message-----
From: Unmoderated discussion of advanced .NET topics.
[mailto:ADVANCED-DOTNET@DISCUSS.DEVELOP.COM] On Behalf Of Kamen Lilov
Sent: Tuesday, September 13, 2005 1:15 PM
To: ADVANCED-DOTNET@DIS­CUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] Business logic

Owen,
instead, we'll probably migrate all the logic into an RDBMS-agnostic
middle tier and use>> only ANSI-92 SQL interactions through a generic ODBC endpoint.

That won't get you nowhere. Or rather, it will get you to a situation
where your app nearly works, but with terrible performance on each and
every database.

Instead, migrate all the logic into a data tier whose API is
RDBMS-agnostic, and is called by your main application, then write two
copies (binary compatible on an API level, probably using some kind of
plug-in-like
architecture) of the data tier - one for SQL Server, one for Oracle, and
so on.

I've also seen people doing it all in one place and #ifdef-ing depending
on the RDBMS, but I suspect this is very error-prone (never been there
myself
though)

Regards,
Kamen Lilov
Delera Systems
http://www.delera.c­om/blog/


-----Original Message-----
From: Unmoderated discussion of advanced .NET topics.
[mailto:ADVANCED-DOTNET@DISCUSS.DEVELOP.COM] On Behalf Of Jeff Ferguson
Sent: Tuesday, September 13, 2005 1:04 PM
To: ADVANCED-DOTNET@DIS­CUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] Business logic
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.

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

===================­================
This list is hosted by DevelopMentor. 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

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

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

Add comment
Chip Dunning 13 September 2005 20:30:21 permanent link ]
 It depends highly on where those making the decisions are coming from.
Programmers tend to favor n-teir approaches where tasks are divided into
buckets that preform their assigned role. DBAs tend to push as much as
possible into the database engine letting the rest of the app to handle the
interface.

I am a programmer - thus I tend to find the idea of keeping business logic
in the primitive database languages available abhorrant. I like to keep the
ability to completely ripout the business logic if necessary have have it
affect the other parts as little as possible.



Chip

On 9/13/05, Owen Cunningham <ocunning@zantaz.co­m> wrote:>
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>



--
"The reason the mainstream is considered a stream is because it's so
shallow" --George Carlin

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

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

Add comment
Mike A 13 September 2005 20:32:39 permanent link ]
 Adding to the debate just a little, the conclusion I've come to for 4-tier.

The client is obvious and should be wholly disconnected from the business
tier. The business tier, totally disconnected from the data tier can sit
anywhere: at the client, the data server or another server, all without any
degradation in processing. For this reason I don't use abstract, builder, or
other factory classes in the business tier but for speed use simple
call-fetch processing.

The data processing tier is where the heart of the work is done before
sending results to the business tier. It is then wholly disposed of
(finalized). This is where my factory classes sit. It is totally
disconnected from the datacentre(datacent­er) tier, a thin data fetcher.

I notice from the MS PDC today that this method conforms very well with the
new system Superfetch and it's resulting "sand boxing" concept.

Mike A



--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.10.23/99 - Release Date: 12/09/2005

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

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

Add comment
Mike A 13 September 2005 21:03:48 permanent link ]
 Chip Dunning wrote:> I am a programmer - thus I tend to find the idea of keeping business> logic in the primitive database languages available abhorrant. I like> to keep the ability to completely ripout the business logic if> necessary have have it affect the other parts as little as possible.

Huge applause!

Whilst following this thread I've been viewing/listening to the MS PDC. Does
anyone notice the similarities between what MS are saying for their whole
development future from 2006 and tier disconnection? Taken them on board?



--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.10.23/99 - Release Date: 12/09/2005

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

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

Add comment
Ernst Kuschke 13 September 2005 21:10:27 permanent link ]
 Business rules are the ones changing more than anything else - I'm not sure
changing your database will be the best place for this!

On 9/13/05, Jeff Ferguson <jefff@magenic.com>­ wrote: >
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.>
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>

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

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

Add comment
J. Merrill 13 September 2005 22:53:50 permanent link ]
 At 01:12 PM 9/13/2005, Steve Johnson wrote>On 9/13/05, Alex Smotritsky <alex_smotritsky@ya­hoo.com> wrote:>>
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.>>
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

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 http://www.develop.­com

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

Add comment
Chip Dunning 13 September 2005 23:27:55 permanent link ]
 Not a big fan of ZDNet, but this (http://blogs.zdnet­.com/Ou/?p=71) talks
about Oracle's Grid computing.

I guess if you thrown an infinite amount of cash you can get Oracle Grid to
infinitly scale, but I worked for 2 years in an Oracle Grid/Cluster
environment and it was nice - but nothing that really special. More
marketing hype that boots on the ground reality. Still, after enough money
thrown at the back-end it out-performed the old system and management
christened the transition a success.

My personal beliefs is to let each tier of the system do what it does best.
When you try to shoehorn the wrong thing into one level of the tier you end
up with bottlenecks and fragile systems. Business Logic no more belongs in
the database layer than the GUI belongs in the business layer.

Thus if the GUI layer needs more horsepower I can scale that - if the data
layer needs more horsepower I can scale that. If my business layer is
running just happy then let it alone. When changes to business come along
the data and GUI layers do not have to be changed - simply change the
business rules.

I grew to enjoy PL/SQL during those years, but its full-fledged capabilities
are still years behind modern development languages.

A grid of screwdrivers is no more suited to driving in a name than a single
large screwdriver. Of course, if the only tool you have in your toolbox is a
bunch of screwdrivers - then everyone is going to get screwed.



Chip

On 9/13/05, J. Merrill <jvm_cop@spamcop.ne­t> wrote:>
At 01:12 PM 9/13/2005, Steve Johnson wrote> >On 9/13/05, Alex Smotritsky <alex_smotritsky@ya­hoo.com> wrote:> >>
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.> >>
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>
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>



--
"The reason the mainstream is considered a stream is because it's so
shallow" --George Carlin

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

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

Add comment
Kamen Lilov 14 September 2005 00:03:06 permanent link ]
 
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?

Don't know if many people have done this, but I'm one of those guys who's
actually architected and deployed a system running on Oracle 10g with a real
RAC underneath.

As much as I love MS SQL Server and hate Oracle's licensing (or, more
appropriately, 'extortion') policy, I have to say it works fantastic. At
least in our configuration - 2 boxes connected to a SAN via fibre. The two
machines are configured so they start replying to a single IP; I can pull
the plug on one of them while it's performing updates, and the only
transaction that gets lost is the one on the machine that just went dead.
No hanging locks, no nothing - instant recovery. And yes they _do_
load-balance requests appropriately.

Microsoft are far, far, far away from doing this with their partitioned
tables and log cra... umm... Log shipping.

I'm not sure how well Oracle works on a 'large number of commodity servers'
though. People who've done very large SAN installations say the absolute
maximum number of database servers connected to a single SAN is 8 - and that
is if you have one of those 7-fugure SAN units.

The moment you leave the 'grid of X boxes connected to a SAN' and go to
'grid of X boxes holding a couple of databases spread across the place' you
lose the scalability you're talking of.

And when somebody says 'large number of commodity servers' I tend to think
Google's hundreds (are they thousands already) of machines running in a
single location. Repeat that two dozen times with multiple locations :)­


Regards,
Kamen Lilov
Delera Systems
http://www.delera.c­om/blog/

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

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

Add comment
Jeff Little 14 September 2005 00:07:34 permanent link ]
 Kudos for this post! I am always inclined to chuckle at the various
initiatives that are undertaken to "standardize" development, architecture,
etc. So many of the books and blogs have that "fire and brimstone" approach
-- this is the ONLY way to achieve such and such. . . I even know of a
working group of executives that has as one of its goals "the
standardization of flexible delivery." Huh?? Does the term oxymoron mean
anything . . .

If a company wants to spend zillions on an Oracle grid/cluster, more power
to them. It is a pretty rarified few, however, who would achieve tangible
benefit from such a structure. Sort of like owning a Ferrari in Manhattan
-- kind of neat, but really doesn't do anything for you.

We forget that a substantial segment of the business community lives off of
Excel spreadsheets, where "scalable" means a new macro. My first assignment
ever was working for a big bank, and engineering a process that would pull
from a couple of AS400 installations, 2 or 3 SQL Servers and some Access
databases, and dump them all into an Excel spreadsheet!

As Chip said, let the tiers do what they do best, UNDER THE CIRCUMSTANCES OF
THE PARTICULAR PROBLEM DOMAIN. In some settings, you would really be
forcing things to even come up with things to put in a separate Business
Logic tier, while in other settings, you feel like you need 7 or 8 tiers. A
good design is one that achieves the best possible blend of performance,
ease of use, cost effectiveness and scalability, given the end goal.

Just debated this with a colleague who is an ardent C++ guy, and who looks
down his nose at pedestrian technologies such as .NET, C#, etc. So, sorry
for pontificating. ;-)­

Jeff

-----Original Message-----
From: Unmoderated discussion of advanced .NET topics.
[mailto:ADVANCED-DOTNET@DISCUSS.DEVELOP.COM] On Behalf Of Chip Dunning
Sent: Tuesday, September 13, 2005 4:28 PM
To: ADVANCED-DOTNET@DIS­CUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] Business logic

Not a big fan of ZDNet, but this (http://blogs.zdnet­.com/Ou/?p=71) talks
about Oracle's Grid computing.

I guess if you thrown an infinite amount of cash you can get Oracle Grid to
infinitly scale, but I worked for 2 years in an Oracle Grid/Cluster
environment and it was nice - but nothing that really special. More
marketing hype that boots on the ground reality. Still, after enough money
thrown at the back-end it out-performed the old system and management
christened the transition a success.

My personal beliefs is to let each tier of the system do what it does best.
When you try to shoehorn the wrong thing into one level of the tier you end
up with bottlenecks and fragile systems. Business Logic no more belongs in
the database layer than the GUI belongs in the business layer.

Thus if the GUI layer needs more horsepower I can scale that - if the data
layer needs more horsepower I can scale that. If my business layer is
running just happy then let it alone. When changes to business come along
the data and GUI layers do not have to be changed - simply change the
business rules.

I grew to enjoy PL/SQL during those years, but its full-fledged capabilities

are still years behind modern development languages.

A grid of screwdrivers is no more suited to driving in a name than a single
large screwdriver. Of course, if the only tool you have in your toolbox is a

bunch of screwdrivers - then everyone is going to get screwed.



Chip

On 9/13/05, J. Merrill <jvm_cop@spamcop.ne­t> wrote:>
At 01:12 PM 9/13/2005, Steve Johnson wrote> >On 9/13/05, Alex Smotritsky <alex_smotritsky@ya­hoo.com> wrote:> >>
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.> >>
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>
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>



--
"The reason the mainstream is considered a stream is because it's so
shallow" --George Carlin

===================­================
This list is hosted by DevelopMentorR http://www.develop.­com

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

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

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

Add comment
Shawn Wildermuth 14 September 2005 00:26:58 permanent link ]
 I've been listening to this post quiet in a corner. What I think is
important to understand is that based on a projects particular requirements
(technical, functional and business), there could be very different
solutions.

For example, I worked at an un-named company where we had invested about a
year into the development of a search engine on-top of SQL Server. In our
side-by-side comparisons, Oracle had always lost in performance because of
our particular search needs (for the record Oracle usually beats SQL Server
on straight Full-Text Searches, but SQL Server's query optimizer made the
overall tests outperform). Then the word came down the pike that we had to
switch it to work on Oracle...because they wanted to get a big contract with
Oracle for their product. 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.


Thanks,

Shawn Wildermuth
http://adoguy.com
C# MVP, MCSD.NET, Author and Speaker

->-----Original Message-----
->From: Unmoderated discussion of advanced .NET topics.
->[mailto:ADVANCED-DOTNET@DISCUSS.DEVELOP.COM] On Behalf Of Jeff Little
->Sent: Tuesday, September 13, 2005 5:08 PM
->To: ADVANCED-DOTNET@DIS­CUSS.DEVELOP.COM
->Subject: Re: [ADVANCED-DOTNET] Business logic
->
->Kudos for this post! I am always inclined to chuckle at the
->various initiatives that are undertaken to "standardize"
->development, architecture, etc. So many of the books and
->blogs have that "fire and brimstone" approach
->-- this is the ONLY way to achieve such and such. . . I
->even know of a
->working group of executives that has as one of its goals "the
->standardization of flexible delivery." Huh?? Does the term
->oxymoron mean anything . . .
->
->If a company wants to spend zillions on an Oracle
->grid/cluster, more power to them. It is a pretty rarified
->few, however, who would achieve tangible benefit from such a
->structure. Sort of like owning a Ferrari in Manhattan
->-- kind of neat, but really doesn't do anything for you.
->
->We forget that a substantial segment of the business
->community lives off of Excel spreadsheets, where "scalable"
->means a new macro. My first assignment ever was working for
->a big bank, and engineering a process that would pull from a
->couple of AS400 installations, 2 or 3 SQL Servers and some
->Access databases, and dump them all into an Excel spreadsheet!
->
->As Chip said, let the tiers do what they do best, UNDER THE
->CIRCUMSTANCES OF THE PARTICULAR PROBLEM DOMAIN. In some
->settings, you would really be forcing things to even come up
->with things to put in a separate Business Logic tier, while
->in other settings, you feel like you need 7 or 8 tiers. A
->good design is one that achieves the best possible blend of
->performance, ease of use, cost effectiveness and scalability,
->given the end goal.
->
->Just debated this with a colleague who is an ardent C++ guy,
->and who looks down his nose at pedestrian technologies such
->as .NET, C#, etc. So, sorry for pontificating. ;-)­
->
->Jeff
->
->-----Original Message-----
->From: Unmoderated discussion of advanced .NET topics.
->[mailto:ADVANCED-DOTNET@DISCUSS.DEVELOP.COM] On Behalf Of Chip Dunning
->Sent: Tuesday, September 13, 2005 4:28 PM
->To: ADVANCED-DOTNET@DIS­CUSS.DEVELOP.COM
->Subject: Re: [ADVANCED-DOTNET] Business logic
->
->Not a big fan of ZDNet, but this
->(http://blogs.zdn­et.com/Ou/?p=71) talks about Oracle's Grid computing.
->
->I guess if you thrown an infinite amount of cash you can get
->Oracle Grid to infinitly scale, but I worked for 2 years in
->an Oracle Grid/Cluster environment and it was nice - but
->nothing that really special. More marketing hype that boots
->on the ground reality. Still, after enough money thrown at
->the back-end it out-performed the old system and management
->christened the transition a success.
->
->My personal beliefs is to let each tier of the system do what
->it does best.
->When you try to shoehorn the wrong thing into one level of
->the tier you end up with bottlenecks and fragile systems.
->Business Logic no more belongs in the database layer than the
->GUI belongs in the business layer.
->
->Thus if the GUI layer needs more horsepower I can scale that
->- if the data layer needs more horsepower I can scale that.
->If my business layer is running just happy then let it alone.
->When changes to business come along the data and GUI layers
->do not have to be changed - simply change the business rules.
->
->I grew to enjoy PL/SQL during those years, but its
->full-fledged capabilities
->
->are still years behind modern development languages.
->
->A grid of screwdrivers is no more suited to driving in a name
->than a single large screwdriver. Of course, if the only tool
->you have in your toolbox is a
->
->bunch of screwdrivers - then everyone is going to get screwed.
->
->
->
->Chip
->
->On 9/13/05, J. Merrill <jvm_cop@spamcop.ne­t> wrote:
->>
->> At 01:12 PM 9/13/2005, Steve Johnson wrote
->> >On 9/13/05, Alex Smotritsky <alex_smotritsky@ya­hoo.com> wrote:
->> >>
->> >> 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.
->> >>
->> >
->> >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
->>
->> 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
->>
->
->
->
->--
->"The reason the mainstream is considered a stream is because
->it's so shallow" --George Carlin
->
->=================­==================
->This list is hosted by DevelopMentorR http://www.develop.­com
->
->View archives and manage your subscription(s) at
->http://discuss.de­velop.com
->
->=================­==================
->This list is hosted by DevelopMentor. http://www.develop.­com
->
->View archives and manage your subscription(s) at
->http://discuss.de­velop.com
09/13/2005 05:12:22 PM

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

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

Add comment
Franklin Gray 14 September 2005 01:10:07 permanent link ]
 ""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".

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

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

Add comment


Shawn Wildermuth 14 September 2005 01:17:33 permanent link ]
 Yes and no. I would probably not put it in the database, but that doesn't
mean its wrong. The fact of the matter is that even outside the database
(ours was entirely outside the database), it still required a major
re-write. Database independence is a falicy. Keeping your logic outside
the DB doesn't buy you much unless you are doing strict SQL '92/95...which
no one does because it performs like a dog. But DB Independence is an
entirely different topic that I don't want to get caught walking the tangent
gangplank ;)

Thanks,

Shawn Wildermuth
http://adoguy.com
C# MVP, MCSD.NET, Author and Speaker

->-----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 6:10 PM
->To: ADVANCED-DOTNET@DIS­CUSS.DEVELOP.COM
->Subject: Re: [ADVANCED-DOTNET] Business logic
->
->""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".
->
->=================­==================
->This list is hosted by DevelopMentor. http://www.develop.­com
->
->View archives and manage your subscription(s) at
->http://discuss.de­velop.com
09/13/2005 06:15:13 PM

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

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

Add comment
Shawn Wildermuth 14 September 2005 01:19:09 permanent link ]
 What I mean to say is that each enterprises needs are so varied that we can
provide some aid in finding gotchas on a list like this, but you really need
a thorough investigation into the requirements and find the right solution.
Pat answers like "Never put the business logic in the DB" are rarely helpful
in those situations, IMNSHO.

Thanks,

Shawn Wildermuth
http://adoguy.com
C# MVP, MCSD.NET, Author and Speaker

->-----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 6:10 PM
->To: ADVANCED-DOTNET@DIS­CUSS.DEVELOP.COM
->Subject: Re: [ADVANCED-DOTNET] Business logic
->
->""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".
->
->=================­==================
->This list is hosted by DevelopMentor. http://www.develop.­com
->
->View archives and manage your subscription(s) at
->http://discuss.de­velop.com
09/13/2005 06:17:46 PM

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

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

Add comment


Curt Hagenlocher 14 September 2005 02:10:16 permanent link ]
 From: "Franklin Gray" <franklin.w.gray@US­.ABB.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".

The decision to plan for future "database independence" is another business
decision -- and one that was hopefully made early on :)­.


From: "Shawn Wildermuth" <swildermuth_lists@­ADOGUY.COM>
Database independence is a fallacy.

+1 to that.

--
Curt Hagenlocher
curt@hagenlocher.or­g

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

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

Add comment
Paul Tiseo 14 September 2005 04:20:04 permanent link ]
 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>
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?

There's been a lot of hemming and hawing on your topic. In part, it's
probably because we should define what is meant by "business rules", which
is a grossly broad topic.

If the rule relates to (simple and/or essential) maintanace of data
integrity, then it should be as close to the db backend as possible. Moreso
if the db backend supplies many different applications.

If we are talking rules between the objects that form the application, then
obviously those reside in the higher layers. Some of those can get very
convoluted.

Furthermore, some people implement the same rules in multiple layers. This
is common in enterprise apps, where multiple development projects
cross-pollinate multiple databases. There, a single bad programmwer can hose
multiple backend systems. Redundancy in rules is a good thing.

An interesting artcile on how the data layer could/should actually be
considered a separate and isolated application, rather than a layer in your
application, can be found at:
http://www.theserve­rside.net/articles/s­howarticle.tss?id=Fa­llacyDataLayer

So to say to "put all rules in <layer name>" is a generalization, and like
most generalization, is generally untrue. :)­

___________________­____________
Paul Tiseo
ptiseo@metacodestud­ios.com

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

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

Add comment


Frans Bouma 14 September 2005 09:26:52 permanent link ]
 
From: "Shawn Wildermuth" <swildermuth_lists@­ADOGUY.COM>>
Database independence is a fallacy.>
+1 to that.

No it's not. With the proper O/R mapper, true db independence is a reality.