Is this a good application Design?

[Jay Balapa]

Hello,

Currently my application has three tiers-

1. Presentation Layer (Asp.Net / Win Forms/ Pocket PC UI.)
This predominantly contains User Controls, Custom Controls and Win/Web
Forms.
I have one base form and I inherit from that form.
All validation is done in this tier. There is zero Data Access code in this
tier. This tier exclusively gets DataViews/ Arays/Lists as input. Outputs
are string objects with SQL Statements or just paremeters with
dataconnection key.

2. Business Layer.
Currently this is just a Library residing in the same machine as
Presentation layer. Eventually I plan to use WebServices if application
needs physical seperation.
Most of Business Logic are implemented in this layer. There is absolutely no
UI code here.
These are all bunch of static methods which perform CRUD functionality.
All methods are atomic in nature. I dont rely on Static Variables. There is
just one DatabaseGateway class which does all the functionality.

3. Data Layer. (SQL Server)
I dont use stored procedures. predominantly use Views.
I have been reading up on Rockford Lhotka's business objects and I just feel
that his framework is unnecessarily complex. I just dont see the need to
hold these intermediate Business Objects.

Thanks for your responses.

--
Jay Balapa
Director Of Software Engineering
www.atginc.com

[Josh]

Your SQL should be in the Business Layer. The presentation layer should not
make or provide decisions on how data is collected ( that what tables / view
or columns are used ) as that is a business rule.

"Jay Balapa" <jb*****@hotmail.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

Hello,

Currently my application has three tiers-

1. Presentation Layer (Asp.Net / Win Forms/ Pocket PC UI.)
This predominantly contains User Controls, Custom Controls and Win/Web
Forms.
I have one base form and I inherit from that form.
All validation is done in this tier. There is zero Data Access code in
this tier. This tier exclusively gets DataViews/ Arays/Lists as input.
Outputs are string objects with SQL Statements or just paremeters with
dataconnection key.

2. Business Layer.
Currently this is just a Library residing in the same machine as
Presentation layer. Eventually I plan to use WebServices if application
needs physical seperation.
Most of Business Logic are implemented in this layer. There is absolutely
no UI code here.
These are all bunch of static methods which perform CRUD functionality.
All methods are atomic in nature. I dont rely on Static Variables. There
is just one DatabaseGateway class which does all the functionality.

3. Data Layer. (SQL Server)
I dont use stored procedures. predominantly use Views.
I have been reading up on Rockford Lhotka's business objects and I just
feel that his framework is unnecessarily complex. I just dont see the need
to hold these intermediate Business Objects.

Thanks for your responses.

--
Jay Balapa
Director Of Software Engineering
www.atginc.com

[Jay Balapa]

Josh,

Thanks for your response.

SQL most of the time is in the Business layer.

Sometimes I need to iterate Datarows in a Datagrid. In those cases I make
that exception.

--
Jay
"Josh" <[e-mail]> wrote in message
news:OS**************@TK2MSFTNGP10.phx.gbl...

Your SQL should be in the Business Layer. The presentation layer should
not make or provide decisions on how data is collected ( that what tables
/ view or columns are used ) as that is a business rule.

"Jay Balapa" <jb*****@hotmail.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

Hello,

Currently my application has three tiers-

1. Presentation Layer (Asp.Net / Win Forms/ Pocket PC UI.)
This predominantly contains User Controls, Custom Controls and Win/Web
Forms.
I have one base form and I inherit from that form.
All validation is done in this tier. There is zero Data Access code in
this tier. This tier exclusively gets DataViews/ Arays/Lists as input.
Outputs are string objects with SQL Statements or just paremeters with
dataconnection key.

2. Business Layer.
Currently this is just a Library residing in the same machine as
Presentation layer. Eventually I plan to use WebServices if application
needs physical seperation.
Most of Business Logic are implemented in this layer. There is absolutely
no UI code here.
These are all bunch of static methods which perform CRUD functionality.
All methods are atomic in nature. I dont rely on Static Variables. There
is just one DatabaseGateway class which does all the functionality.

3. Data Layer. (SQL Server)
I dont use stored procedures. predominantly use Views.
I have been reading up on Rockford Lhotka's business objects and I just
feel that his framework is unnecessarily complex. I just dont see the
need to hold these intermediate Business Objects.

Thanks for your responses.

--
Jay Balapa
Director Of Software Engineering
www.atginc.com

[bradley]

If you want to do away with the complexity of the business objects, then
consider moving this business logic to the database as stored procedures and
triggers.

"Jay Balapa" <jb*****@hotmail.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

Hello,

Currently my application has three tiers-

1. Presentation Layer (Asp.Net / Win Forms/ Pocket PC UI.)
This predominantly contains User Controls, Custom Controls and Win/Web
Forms.
I have one base form and I inherit from that form.
All validation is done in this tier. There is zero Data Access code in this tier. This tier exclusively gets DataViews/ Arays/Lists as input. Outputs
are string objects with SQL Statements or just paremeters with
dataconnection key.

2. Business Layer.
Currently this is just a Library residing in the same machine as
Presentation layer. Eventually I plan to use WebServices if application
needs physical seperation.
Most of Business Logic are implemented in this layer. There is absolutely no UI code here.
These are all bunch of static methods which perform CRUD functionality.
All methods are atomic in nature. I dont rely on Static Variables. There is just one DatabaseGateway class which does all the functionality.

3. Data Layer. (SQL Server)
I dont use stored procedures. predominantly use Views.
I have been reading up on Rockford Lhotka's business objects and I just feel that his framework is unnecessarily complex. I just dont see the need to
hold these intermediate Business Objects.

Thanks for your responses.

--
Jay Balapa
Director Of Software Engineering
www.atginc.com

[Josh]

Keeping the layers truely seperate is difficult. I would suggest that even
if you have to itereate through a result set the SQL should be in the
Business Layer, pass your filter criteria to the business layer.


"Jay Balapa" <jb*****@hotmail.com> wrote in message
news:eD*************@TK2MSFTNGP12.phx.gbl...

Josh,

Thanks for your response.

SQL most of the time is in the Business layer.

Sometimes I need to iterate Datarows in a Datagrid. In those cases I make
that exception.

--
Jay
"Josh" <[e-mail]> wrote in message
news:OS**************@TK2MSFTNGP10.phx.gbl...

Your SQL should be in the Business Layer. The presentation layer should
not make or provide decisions on how data is collected ( that what tables
/ view or columns are used ) as that is a business rule.

"Jay Balapa" <jb*****@hotmail.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

Hello,

Currently my application has three tiers-

1. Presentation Layer (Asp.Net / Win Forms/ Pocket PC UI.)
This predominantly contains User Controls, Custom Controls and Win/Web
Forms.
I have one base form and I inherit from that form.
All validation is done in this tier. There is zero Data Access code in
this tier. This tier exclusively gets DataViews/ Arays/Lists as input.
Outputs are string objects with SQL Statements or just paremeters with
dataconnection key.

2. Business Layer.
Currently this is just a Library residing in the same machine as
Presentation layer. Eventually I plan to use WebServices if application
needs physical seperation.
Most of Business Logic are implemented in this layer. There is
absolutely no UI code here.
These are all bunch of static methods which perform CRUD functionality.
All methods are atomic in nature. I dont rely on Static Variables.
There is just one DatabaseGateway class which does all the
functionality.

3. Data Layer. (SQL Server)
I dont use stored procedures. predominantly use Views.
I have been reading up on Rockford Lhotka's business objects and I just
feel that his framework is unnecessarily complex. I just dont see the
need to hold these intermediate Business Objects.

Thanks for your responses.

--
Jay Balapa
Director Of Software Engineering
www.atginc.com

[Kim Quigley]

I wasn't aware that putting SQL in the business layer was a best practice. I
use SQL Server 2000 with stored procedures and my data layer accesses those
stored procedures. In the business layer, I have logical business objects
with properties and methods. The purpose of having a seperate data layer is
so that if your data source changes (for example: moving from SQL Server to
MySQL) then you only have to modify the data layer. The presentation and
business layers would be unaffected.
"Josh" <[e-mail]> wrote in message
news:OS**************@TK2MSFTNGP10.phx.gbl...

Your SQL should be in the Business Layer. The presentation layer should
not make or provide decisions on how data is collected ( that what tables
/ view or columns are used ) as that is a business rule.

"Jay Balapa" <jb*****@hotmail.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

Hello,

Currently my application has three tiers-

1. Presentation Layer (Asp.Net / Win Forms/ Pocket PC UI.)
This predominantly contains User Controls, Custom Controls and Win/Web
Forms.
I have one base form and I inherit from that form.
All validation is done in this tier. There is zero Data Access code in
this tier. This tier exclusively gets DataViews/ Arays/Lists as input.
Outputs are string objects with SQL Statements or just paremeters with
dataconnection key.

2. Business Layer.
Currently this is just a Library residing in the same machine as
Presentation layer. Eventually I plan to use WebServices if application
needs physical seperation.
Most of Business Logic are implemented in this layer. There is absolutely
no UI code here.
These are all bunch of static methods which perform CRUD functionality.
All methods are atomic in nature. I dont rely on Static Variables. There
is just one DatabaseGateway class which does all the functionality.

3. Data Layer. (SQL Server)
I dont use stored procedures. predominantly use Views.
I have been reading up on Rockford Lhotka's business objects and I just
feel that his framework is unnecessarily complex. I just dont see the
need to hold these intermediate Business Objects.

Thanks for your responses.

--
Jay Balapa
Director Of Software Engineering
www.atginc.com

[Chad Z. Hower aka Kudzu]

"Jay Balapa" <jb*****@hotmail.com> wrote in
news:#z**************@tk2msftngp13.phx.gbl:

Thanks for your responses.

http://www.codeproject.com/useritems...inessLogic.asp
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Blog: http://blogs.atozed.com/kudzu

[Chad Z. Hower aka Kudzu]

"Jay Balapa" <jb*****@hotmail.com> wrote in
news:#z**************@tk2msftngp13.phx.gbl:

3. Data Layer. (SQL Server)
I dont use stored procedures. predominantly use Views.

Views are good - BUT with SQL Server result set based stored procedures are typcially better
because of SQL servers optimization techniques. Newer versions are adressing this, but as to how
much I dont know yet.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Blog: http://blogs.atozed.com/kudzu

[Chad Z. Hower aka Kudzu]

"Kim Quigley" <ki********@hotmail.com> wrote in
news:#n**************@TK2MSFTNGP14.phx.gbl:

I wasn't aware that putting SQL in the business layer was a best
practice. I use SQL Server 2000 with stored procedures and my data
layer accesses those stored procedures. In the business layer, I have

There are opposing schools of thought here. You will find advice telling you both ways, and some
saying to mix it.

--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Blog: http://blogs.atozed.com/kudzu

[Chad Z. Hower aka Kudzu]

"bradley" <so*****@microsoft.com> wrote in
news:#9**************@TK2MSFTNGP15.phx.gbl:

If you want to do away with the complexity of the business objects,
then consider moving this business logic to the database as stored
procedures and triggers.

There are of course many schools of thought, but personally I would never recommend that. If
you want my views as to why, you can read the link that I just posted.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Blog: http://blogs.atozed.com/kudzu

[Chris Simmons]

I'm only starting on Lhotka's book (which Jay here mentions), but I
think the author recommends putting the data access in with the
Business Objects, but only as static CRUD methods. Then, the
assemblies are duplicated on the three "internal" layers (Presentation,
Business, Data Access). Unknown whether it is a best practice or not,
however it allows the actual "instantiatable" BOs to be fully
black-box, while still allowing the data access code full access to the
BO's internals ... at least how I'm reading it.

So far (about 80 pages in), the book is quite good.

[Eliyahu Goldin]

I am not sure what are you getting to by insisting on moving the SQL to the
business layer. It looks to me like insisting on the dotnet framework to
belong to one layer only.

A database consists of tables, view, stored procedures, triggers etc. Tables
and views belong to data layer. Stored procedures and triggers can be in
either data or business layer. It won't hurt the SQL server if it will
contain elements of both levels.

Eliyahu

"Josh" <[e-mail]> wrote in message
news:uG**************@tk2msftngp13.phx.gbl...

Keeping the layers truely seperate is difficult. I would suggest that even if you have to itereate through a result set the SQL should be in the
Business Layer, pass your filter criteria to the business layer.


"Jay Balapa" <jb*****@hotmail.com> wrote in message
news:eD*************@TK2MSFTNGP12.phx.gbl...

Josh,

Thanks for your response.

SQL most of the time is in the Business layer.

Sometimes I need to iterate Datarows in a Datagrid. In those cases I make that exception.

--
Jay
"Josh" <[e-mail]> wrote in message
news:OS**************@TK2MSFTNGP10.phx.gbl...

Your SQL should be in the Business Layer. The presentation layer should not make or provide decisions on how data is collected ( that what tables / view or columns are used ) as that is a business rule.

"Jay Balapa" <jb*****@hotmail.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
Hello,

Currently my application has three tiers-

1. Presentation Layer (Asp.Net / Win Forms/ Pocket PC UI.)
This predominantly contains User Controls, Custom Controls and Win/Web Forms.
I have one base form and I inherit from that form.
All validation is done in this tier. There is zero Data Access code in
this tier. This tier exclusively gets DataViews/ Arays/Lists as input. Outputs are string objects with SQL Statements or just paremeters with
dataconnection key.

2. Business Layer.
Currently this is just a Library residing in the same machine as
Presentation layer. Eventually I plan to use WebServices if application needs physical seperation.
Most of Business Logic are implemented in this layer. There is
absolutely no UI code here.
These are all bunch of static methods which perform CRUD functionality. All methods are atomic in nature. I dont rely on Static Variables.
There is just one DatabaseGateway class which does all the
functionality.

3. Data Layer. (SQL Server)
I dont use stored procedures. predominantly use Views.
I have been reading up on Rockford Lhotka's business objects and I just feel that his framework is unnecessarily complex. I just dont see the
need to hold these intermediate Business Objects.

Thanks for your responses.

--
Jay Balapa
Director Of Software Engineering
www.atginc.com

[Eliyahu Goldin]

Sometimes it is the best practice. You can change from one platform to
another without affecting the business logic implemented in stored
procedures.

Eliyahu

"Kim Quigley" <ki********@hotmail.com> wrote in message
news:%2******************@TK2MSFTNGP14.phx.gbl...

I wasn't aware that putting SQL in the business layer was a best practice. I use SQL Server 2000 with stored procedures and my data layer accesses those stored procedures. In the business layer, I have logical business objects
with properties and methods. The purpose of having a seperate data layer is so that if your data source changes (for example: moving from SQL Server to MySQL) then you only have to modify the data layer. The presentation and
business layers would be unaffected.
"Josh" <[e-mail]> wrote in message
news:OS**************@TK2MSFTNGP10.phx.gbl...

Your SQL should be in the Business Layer. The presentation layer should
not make or provide decisions on how data is collected ( that what tables / view or columns are used ) as that is a business rule.

"Jay Balapa" <jb*****@hotmail.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

Hello,

Currently my application has three tiers-

1. Presentation Layer (Asp.Net / Win Forms/ Pocket PC UI.)
This predominantly contains User Controls, Custom Controls and Win/Web
Forms.
I have one base form and I inherit from that form.
All validation is done in this tier. There is zero Data Access code in
this tier. This tier exclusively gets DataViews/ Arays/Lists as input.
Outputs are string objects with SQL Statements or just paremeters with
dataconnection key.

2. Business Layer.
Currently this is just a Library residing in the same machine as
Presentation layer. Eventually I plan to use WebServices if application
needs physical seperation.
Most of Business Logic are implemented in this layer. There is absolutely no UI code here.
These are all bunch of static methods which perform CRUD functionality.
All methods are atomic in nature. I dont rely on Static Variables. There is just one DatabaseGateway class which does all the functionality.

3. Data Layer. (SQL Server)
I dont use stored procedures. predominantly use Views.
I have been reading up on Rockford Lhotka's business objects and I just
feel that his framework is unnecessarily complex. I just dont see the
need to hold these intermediate Business Objects.

Thanks for your responses.

--
Jay Balapa
Director Of Software Engineering
www.atginc.com

[Steve Walker]

In message <Xn**************************@127.0.0.1>, Chad Z. Hower aka
Kudzu <cp**@hower.org> writes

"bradley" <so*****@microsoft.com> wrote in
news:#9**************@TK2MSFTNGP15.phx.gbl:

If you want to do away with the complexity of the business objects,
then consider moving this business logic to the database as stored
procedures and triggers.

There are of course many schools of thought, but personally I would
never recommend that. If
you want my views as to why, you can read the link that I just posted.

Agree. For one thing, TSQL is a horrible language to do anything
non-trivial in.

--
Steve Walker

[Eliyahu Goldin]

With SQL Server 2005 you can write stored procedures etc. in c#.

Eliyahu

"Steve Walker" <st***@otolith.demon.co.uk> wrote in message
news:Iv**************@otolith.demon.co.uk...

In message <Xn**************************@127.0.0.1>, Chad Z. Hower aka
Kudzu <cp**@hower.org> writes

"bradley" <so*****@microsoft.com> wrote in
news:#9**************@TK2MSFTNGP15.phx.gbl:

If you want to do away with the complexity of the business objects,
then consider moving this business logic to the database as stored
procedures and triggers.

There are of course many schools of thought, but personally I would
never recommend that. If
you want my views as to why, you can read the link that I just posted.

Agree. For one thing, TSQL is a horrible language to do anything
non-trivial in.

--
Steve Walker

[Chad Z. Hower aka Kudzu]

Steve Walker <st***@otolith.demon.co.uk> wrote in
news:Iv**************@otolith.demon.co.uk:

Agree. For one thing, TSQL is a horrible language to do anything
non-trivial in.

Which is one of the many points I point to in the article (or PL/SQL, or whatever)
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Blog: http://blogs.atozed.com/kudzu

[Chad Z. Hower aka Kudzu]

"Eliyahu Goldin" <re*************@monarchmed.com> wrote in news:#LsxRqndFHA.2076
@TK2MSFTNGP15.phx.gbl:

With SQL Server 2005 you can write stored procedures etc. in c#.

Not quite... You can make calls to .NET procedures FROM STored procedures... But even then its not
a good idea in most cases to put your logic in SPs.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Blog: http://blogs.atozed.com/kudzu

[bradley]

T-SQL is an excellent language for implementing business logic that is tied
closely to the database model or database processing. For example, imposing
data constraints or referencing a set of parameters against a lookup table
and returning a value. Of course, it helps is the developer is at least an
intermediate level SQL programmer and familiar with sub-queries, complex
joins, conditional grouping and where clauses, etc.

"Steve Walker" <st***@otolith.demon.co.uk> wrote in message
news:Iv**************@otolith.demon.co.uk...

In message <Xn**************************@127.0.0.1>, Chad Z. Hower aka
Kudzu <cp**@hower.org> writes

"bradley" <so*****@microsoft.com> wrote in
news:#9**************@TK2MSFTNGP15.phx.gbl:

If you want to do away with the complexity of the business objects,
then consider moving this business logic to the database as stored
procedures and triggers.

There are of course many schools of thought, but personally I would
never recommend that. If
you want my views as to why, you can read the link that I just posted.

Agree. For one thing, TSQL is a horrible language to do anything
non-trivial in.

--
Steve Walker

[Steve Walker]

In message <#L**************@TK2MSFTNGP15.phx.gbl>, Eliyahu Goldin
<re*************@monarchmed.com> writes

"Steve Walker" <st***@otolith.demon.co.uk> wrote in message
news:Iv**************@otolith.demon.co.uk...

In message <Xn**************************@127.0.0.1>, Chad Z. Hower aka
Kudzu <cp**@hower.org> writes

>"bradley" <so*****@microsoft.com> wrote in
>news:#9**************@TK2MSFTNGP15.phx.gbl: >> If you want to do away with the complexity of the business objects,
>> then consider moving this business logic to the database as stored
>> procedures and triggers. >There are of course many schools of thought, but personally I would
>never recommend that. If
>you want my views as to why, you can read the link that I just posted.

Agree. For one thing, TSQL is a horrible language to do anything
non-trivial in.

With SQL Server 2005 you can write stored procedures etc. in c#.

Not terribly portable though, is it?

--
Steve Walker

[Chad Z. Hower aka Kudzu]

"bradley" <so*****@microsoft.com> wrote in
news:OX**************@TK2MSFTNGP10.phx.gbl:

T-SQL is an excellent language for implementing business logic that is
tied closely to the database model or database processing. For
I dont think you will find many that agree with you. C#, Java, anything is better at business logic.
example, imposing data constraints or referencing a set of parameters
Data level storage constraints are not business logic.
against a lookup table and returning a value. Of course, it helps is

Data lookups are not business logic.

--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Blog: http://blogs.atozed.com/kudzu

[Jay Balapa]

>>>>>>>>>>>>>>>>
moving this business logic to the database as stored procedures and

>>>>>>>>>>>>>>>

Problem with that approach is our application will have to support ACCESS as
well as SQL Server, in future we might have to deal with Oracle.

We program exclusively on interfaces and not on actual SQL or OLE objects.
By using simple Views we can mask the changes in underlying tables if
needed.

-jay

"bradley" <so*****@microsoft.com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl... If you want to do away with the complexity of the business objects, then
consider moving this business logic to the database as stored procedures
and
triggers.

"Jay Balapa" <jb*****@hotmail.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

Hello,

Currently my application has three tiers-

1. Presentation Layer (Asp.Net / Win Forms/ Pocket PC UI.)
This predominantly contains User Controls, Custom Controls and Win/Web
Forms.
I have one base form and I inherit from that form.
All validation is done in this tier. There is zero Data Access code in

this

tier. This tier exclusively gets DataViews/ Arays/Lists as input.
Outputs
are string objects with SQL Statements or just paremeters with
dataconnection key.

2. Business Layer.
Currently this is just a Library residing in the same machine as
Presentation layer. Eventually I plan to use WebServices if application
needs physical seperation.
Most of Business Logic are implemented in this layer. There is absolutely

no

UI code here.
These are all bunch of static methods which perform CRUD functionality.
All methods are atomic in nature. I dont rely on Static Variables. There

is

just one DatabaseGateway class which does all the functionality.

3. Data Layer. (SQL Server)
I dont use stored procedures. predominantly use Views.
I have been reading up on Rockford Lhotka's business objects and I just

feel

that his framework is unnecessarily complex. I just dont see the need to
hold these intermediate Business Objects.

Thanks for your responses.

--
Jay Balapa
Director Of Software Engineering
www.atginc.com

[Eliyahu Goldin]

Make your mind. Horrible language vs not terribly portable.

Eliyahu

"Steve Walker" <st***@otolith.demon.co.uk> wrote in message
news:ys**************@otolith.demon.co.uk...

In message <#L**************@TK2MSFTNGP15.phx.gbl>, Eliyahu Goldin
<re*************@monarchmed.com> writes

"Steve Walker" <st***@otolith.demon.co.uk> wrote in message
news:Iv**************@otolith.demon.co.uk...

In message <Xn**************************@127.0.0.1>, Chad Z. Hower aka
Kudzu <cp**@hower.org> writes
>"bradley" <so*****@microsoft.com> wrote in
>news:#9**************@TK2MSFTNGP15.phx.gbl:> If you want to do away with the complexity of the business objects,
>> then consider moving this business logic to the database as stored
>> procedures and triggers.There are of course many schools of thought, but personally I would
>never recommend that. If
>you want my views as to why, you can read the link that I just posted. Agree. For one thing, TSQL is a horrible language to do anything
non-trivial in.

With SQL Server 2005 you can write stored procedures etc. in c#.

Not terribly portable though, is it?

--
Steve Walker

[bradley]

> Data lookups are not business logic.

It can be if the business logic is implemented as meta data tables rather
than hard coded conditional branching and looping.

"Chad Z. Hower aka Kudzu" <cp**@hower.org> wrote in message
news:Xn**************************@127.0.0.1...

"bradley" <so*****@microsoft.com> wrote in
news:OX**************@TK2MSFTNGP10.phx.gbl:

T-SQL is an excellent language for implementing business logic that is
tied closely to the database model or database processing. For
I dont think you will find many that agree with you. C#, Java, anything is

better at business logic.

example, imposing data constraints or referencing a set of parameters

Data level storage constraints are not business logic.

against a lookup table and returning a value. Of course, it helps is

Data lookups are not business logic.

--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Blog: http://blogs.atozed.com/kudzu

[bradley]

Look out! The barbarians are at the gate.

"Eliyahu Goldin" <re*************@monarchmed.com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

With SQL Server 2005 you can write stored procedures etc. in c#.

Eliyahu

"Steve Walker" <st***@otolith.demon.co.uk> wrote in message
news:Iv**************@otolith.demon.co.uk...

In message <Xn**************************@127.0.0.1>, Chad Z. Hower aka
Kudzu <cp**@hower.org> writes

"bradley" <so*****@microsoft.com> wrote in
news:#9**************@TK2MSFTNGP15.phx.gbl:
> If you want to do away with the complexity of the business objects,
> then consider moving this business logic to the database as stored
> procedures and triggers.

There are of course many schools of thought, but personally I would
never recommend that. If
you want my views as to why, you can read the link that I just posted.

Agree. For one thing, TSQL is a horrible language to do anything
non-trivial in.

--
Steve Walker

[Chad Z. Hower aka Kudzu]

"bradley" <so*****@microsoft.com> wrote in
news:#o**************@TK2MSFTNGP14.phx.gbl:

Data lookups are not business logic.

It can be if the business logic is implemented as meta data tables
rather than hard coded conditional branching and looping.

Yes, in that case it could be. In such cases I would put in the middle tier, not the database.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Blog: http://blogs.atozed.com/kudzu

[Chad Z. Hower aka Kudzu]

"Jay Balapa" <jb*****@hotmail.com> wrote in
news:O$**************@TK2MSFTNGP10.phx.gbl:

Problem with that approach is our application will have to support
ACCESS as well as SQL Server, in future we might have to deal with
Oracle.
Then you should do it as my article says.
We program exclusively on interfaces and not on actual SQL or OLE
objects. By using simple Views we can mask the changes in underlying
tables if needed.

Thats very good, but views wont do complex transforms. And the matter of views vs sps is a SQL
server one, SQL Server is not efficient with views, use SP "as views" when using SQL server.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Blog: http://blogs.atozed.com/kudzu

[Cor Ligthert]

Steve,

T-SQL is an excellent language for implementing business logic that is
tied
closely to the database model or database processing. For example,
imposing
data constraints or referencing a set of parameters against a lookup table
and returning a value. Of course, it helps is the developer is at least an
intermediate level SQL programmer and familiar with sub-queries, complex
joins, conditional grouping and where clauses, etc.

Not better than English, what is called by non native English speakers often
a very poor language when it comes to symantics. Than it is in my opinion
even English with USA slang and therefore even worse.

Just my thought about it.

Cor

[Nick Malik [Microsoft]]

Hi Jay,

1. Presentation Layer (Asp.Net / Win Forms/ Pocket PC UI.)
This predominantly contains User Controls, Custom Controls and Win/Web
Forms.
I have one base form and I inherit from that form.
All validation is done in this tier. There is zero Data Access code in
this tier. This tier exclusively gets DataViews/ Arays/Lists as input.
All this looks pretty good... but...
Outputs are string objects with SQL Statements or just paremeters with
dataconnection key.
This is a pretty bad idea. Your presentation objects should pass data
views, data sets, lists of business objects, etc, to the business layer.
The presentation layer must not know anything about the persistence
mechanism. Otherwise, you end up with expensive code to maintain.

2. Business Layer.
Currently this is just a Library residing in the same machine as
Presentation layer. Eventually I plan to use WebServices if application
needs physical seperation.
Most of Business Logic are implemented in this layer. There is absolutely
no UI code here.
These are all bunch of static methods which perform CRUD functionality.
All methods are atomic in nature. I dont rely on Static Variables. There
is just one DatabaseGateway class which does all the functionality.
This is a structured programming approach. It is not really my style. I
fail to see how you can truly move business logic through a "God Class." (A
God Class is an antipattern. The God Class sees everything, knows
everything, and does everything. :-). This nearly always violates the
Open-Closed principle and produces fragile code (usually in other layers).
Handing off the difficult part to other layers because it is hard to do it
in the business layer is not my first recommendation.

Note that CRUD functionality is not usually the same as a business rule. In
fact, I would suggest that 90% of the real business rules in your app are
not related at all to CRUD functions. These are database operations.

If your system is truly partitioned this way, then your business logic is in
the presentation layer.
3. Data Layer. (SQL Server)
I dont use stored procedures. predominantly use Views.

I read your subsequent posts about why you don't use stored procs. I
understand and sympathize. However, typically in code, we have a Data
Access Layer that hides the fact that your underlying system is a particular
database. This data access layer does many of the connection and CRUD
operations.

If you truly want to reconsider how to partition the functionality of your
system, create an idea in your head of the purpose for each layer. Write
that purpose in large letters on a white board, divided into sections for
each layer, and then break our the activities of your system into methods
that you will implement in each layer. Write these methods under the
heading. Make sure that the purpose matches the method. If the method
doesn't support, defend, and make sense in light of the purpose, move it or
redefine it.

Your answer is your own. It is much easier to work with that way, and if it
works for you, use it. Don't let an author decide for you... or a geek on a
newsgroup :-).

In my experience, I have found that CRUD is a feature of the data access
layer. Business objects enforce business rules and nothing else.
Presentation layers deal with presentation and format validation. That
allows me to seperate the functions in a way that is easier to maintain.

Consider reading about the "Layers" pattern in the Buschmann book on
patterns.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--

[Steve Walker]

In message <OX**************@TK2MSFTNGP10.phx.gbl>, bradley
<so*****@microsoft.com> writes

"Steve Walker" <st***@otolith.demon.co.uk> wrote in message
news:Iv**************@otolith.demon.co.uk...

In message <Xn**************************@127.0.0.1>, Chad Z. Hower aka
Kudzu <cp**@hower.org> writes

>"bradley" <so*****@microsoft.com> wrote in
>news:#9**************@TK2MSFTNGP15.phx.gbl:
>> If you want to do away with the complexity of the business objects,
>> then consider moving this business logic to the database as stored
>> procedures and triggers.
>
>There are of course many schools of thought, but personally I would
>never recommend that. If
>you want my views as to why, you can read the link that I just posted.
Agree. For one thing, TSQL is a horrible language to do anything
non-trivial in.

T-SQL is an excellent language for implementing business logic that is tied
closely to the database model or database processing. For example, imposing
data constraints or referencing a set of parameters against a lookup table
and returning a value. Of course, it helps is the developer is at least an
intermediate level SQL programmer and familiar with sub-queries, complex
joins, conditional grouping and where clauses, etc.

Speaking personally, I'm familiar with all of those constructs. The fact
that I can program competently in a language doesn't change my opinion
of whether or not it is horrible. TSQL is horrible. It's BASIC with
support for set-based operations and a slightly uglier procedural
syntax.

I'm not saying it isn't useful. It is immensely so. I'm saying I dislike
it, and were it not an absolute necessity of my professional life, I'd
be happy never to write another line of it.

While I'm being rude about other people's pet languages, by the way, the
same goes for XSLT. And yes, I'm reasonably competent in that too.

--
Steve Walker

[Steve Walker]

In message <Oz*************@TK2MSFTNGP15.phx.gbl>, Eliyahu Goldin
<re*************@monarchmed.com> writes

"Steve Walker" <st***@otolith.demon.co.uk> wrote in message
news:ys**************@otolith.demon.co.uk...

In message <#L**************@TK2MSFTNGP15.phx.gbl>, Eliyahu Goldin
<re*************@monarchmed.com> writes

>"Steve Walker" <st***@otolith.demon.co.uk> wrote in message
>news:Iv**************@otolith.demon.co.uk...
>> In message <Xn**************************@127.0.0.1>, Chad Z. Hower aka
>> Kudzu <cp**@hower.org> writes
>> >"bradley" <so*****@microsoft.com> wrote in
>> >news:#9**************@TK2MSFTNGP15.phx.gbl:

>> >> If you want to do away with the complexity of the business objects,
>> >> then consider moving this business logic to the database as stored
>> >> procedures and triggers.

>> >There are of course many schools of thought, but personally I would
>> >never recommend that. If
>> >you want my views as to why, you can read the link that I just posted.

>> Agree. For one thing, TSQL is a horrible language to do anything
>> non-trivial in.

>With SQL Server 2005 you can write stored procedures etc. in c#.

Not terribly portable though, is it?

Make your mind. Horrible language vs not terribly portable.

Using C# from within the database is not terribly portable between
databases. Implementing a tiered design with simple stored procedures
gives you more options and allows you to do what SQL is good at in SQL
and what object oriented languages are good at in object orientated
languages. If presentation, domain model, data access and database logic
(i.e. stored procedures)are all distinct tiers it's relatively easy to
substitute a different platform for any one of them. If the stored
procedures are relatively simple CRUD affairs, you will even be able to
migrate to a platform which doesn't support stored procedures with
relative ease.

--
Steve Walker

[Chad Z. Hower aka Kudzu]

Steve Walker <st***@otolith.demon.co.uk> wrote in
news:TX**************@otolith.demon.co.uk:

Using C# from within the database is not terribly portable between
databases. Implementing a tiered design with simple stored procedures
gives you more options and allows you to do what SQL is good at in SQL
and what object oriented languages are good at in object orientated
languages. If presentation, domain model, data access and database
logic (i.e. stored procedures)are all distinct tiers it's relatively
easy to substitute a different platform for any one of them. If the
stored procedures are relatively simple CRUD affairs, you will even be
able to migrate to a platform which doesn't support stored procedures
with relative ease.

Spot on.

In fact, you can even see performance benefits from this approach, as well as more scalable
deployments.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Blog: http://blogs.atozed.com/kudzu

[Michael Rodriguez]

"Chad Z. Hower aka Kudzu" <cp**@hower.org> wrote in message
news:Xn**************************@127.0.0.1...

"bradley" <so*****@microsoft.com> wrote in
news:#9**************@TK2MSFTNGP15.phx.gbl:

If you want to do away with the complexity of the business objects,
then consider moving this business logic to the database as stored
procedures and triggers.

There are of course many schools of thought, but personally I would never
recommend that. If
you want my views as to why, you can read the link that I just posted.

Chad,

I have to respectively disagree with you. There are several instances where
the business logic should be in the stored procedures. Suppose you have a
posting procedure that needs to compute the average cost of items based on
thousands of invoices, then post those costs to another table. In order to
do that logic in the business tier, you would have to retrieve all of the
relevant data locally, crunch it, then send it back to the DB server in
another form. This defeats the whole purpose of having a database server to
begin with. Now you're back to the FoxPro days where the network bandwith
was sucked up by thousands and thousands of rows of data being sent back and
forth across the network for processing. One of the main advantages of
having a database server is to let it crunch (read - perform logic) all the
data and return only the much smaller result set.

I'm not saying your approach is necessarily incorrect. That would work
great if you were dealing with small chunks of data. But when you have to
insert values into tables based on numbers computed from thousands of rows
of data in other tables, I think it's best to let the DB server do all of
the work for you. That way nothing has to travel across a wire.

My $.02

Mike Rodriguez

[Chad Z. Hower aka Kudzu]

"Michael Rodriguez" <mi**@nospamforme.com> wrote in
news:Oe**************@TK2MSFTNGP09.phx.gbl:

I have to respectively disagree with you. There are several instances
where the business logic should be in the stored procedures. Suppose
you have a posting procedure that needs to compute the average cost of
items based on thousands of invoices, then post those costs to another

These exceptions are rare, and if you read the URL I posted, I even covered this. These account for <
1% of business logic, yet most systems implement often half of their business logic in the
datbase.

Even in this case, its a simle matter of running a grouping query, dividing and reposting. There are
complex cases though beyond your example that definitely need to be in an SP, but again they are
rare.

--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Blog: http://blogs.atozed.com/kudzu

[Michael Rodriguez]

"Chad Z. Hower aka Kudzu" <cp**@hower.org> wrote in message
news:Xn*************************@127.0.0.1...

"Michael Rodriguez" <mi**@nospamforme.com> wrote in
news:Oe**************@TK2MSFTNGP09.phx.gbl:

I have to respectively disagree with you. There are several instances
where the business logic should be in the stored procedures. Suppose
you have a posting procedure that needs to compute the average cost of
items based on thousands of invoices, then post those costs to another

These exceptions are rare, and if you read the URL I posted, I even
covered this. These account for <
1% of business logic, yet most systems implement often half of their
business logic in the
datbase.

I have to admit I have a rare application! We do accounting for restaurants
and everything is based on theoretical food costs, which involves a lot of
data to compute. Many of my posting stored procedures are contain over 500+
lines of T-SQL code. As much as I would like that work done in the business
layer, it just isn't practical in our case.

I did like your article, though. Nice work.

Mike

[Chad Z. Hower aka Kudzu]

"Michael Rodriguez" <mi**@nospamforme.com> wrote in
news:e8**************@tk2msftngp13.phx.gbl:

I have to admit I have a rare application! We do accounting for
restaurants and everything is based on theoretical food costs, which
involves a lot of data to compute. Many of my posting stored
procedures are contain over 500+ lines of T-SQL code. As much as I
would like that work done in the business layer, it just isn't
practical in our case.
Exceptional cases do exist. :) But in most business applications such calculations that can be done
with measureable diference in performance in the SP's versus the business layer are a small
amount.

I dont envy the large SP's you have to maintain. I once designed a system to track trades, which we
thousands per second. We had to build big calcuation and aggregation servers becuase not even the
DB could keep up.
I did like your article, though. Nice work.

Thanks. I hope you found something useful. Please feel free to pass it around and dont forget to
vote in the bottom right. :)

Its actually the first in a series of articles, so keep your eyes open.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Blog: http://blogs.atozed.com/kudzu

[Michael Rodriguez]

"Chad Z. Hower aka Kudzu" <cp**@hower.org> wrote in message
news:Xn*************************@127.0.0.1...

Exceptional cases do exist. :) But in most business applications such
calculations that can be done
with measureable diference in performance in the SP's versus the business
layer are a small
amount.

I dont envy the large SP's you have to maintain. I once designed a system
to track trades, which we
thousands per second. We had to build big calcuation and aggregation
servers becuase not even the
DB could keep up.

It's really a very fine line. If you have a system where hundreds of users
are crunching loads of data, which poison do you pick? Do you do all the
work in stored procedures (= database bottleneck), or do you send everything
back to the clients and distribute the processing (= network bottleneck).
We're still trying to figure it out...

Mike

[BiesemansK]

For good architectures read on:
http://msdn.microsoft.com/practices/...s/default.aspx

Kurt

"Eliyahu Goldin" wrote:

I am not sure what are you getting to by insisting on moving the SQL to the
business layer. It looks to me like insisting on the dotnet framework to
belong to one layer only.

A database consists of tables, view, stored procedures, triggers etc. Tables
and views belong to data layer. Stored procedures and triggers can be in
either data or business layer. It won't hurt the SQL server if it will
contain elements of both levels.

Eliyahu

"Josh" <[e-mail]> wrote in message
news:uG**************@tk2msftngp13.phx.gbl...

Keeping the layers truely seperate is difficult. I would suggest that

even

if you have to itereate through a result set the SQL should be in the
Business Layer, pass your filter criteria to the business layer.


"Jay Balapa" <jb*****@hotmail.com> wrote in message
news:eD*************@TK2MSFTNGP12.phx.gbl...

Josh,

Thanks for your response.

SQL most of the time is in the Business layer.

Sometimes I need to iterate Datarows in a Datagrid. In those cases I make that exception.

--
Jay
"Josh" <[e-mail]> wrote in message
news:OS**************@TK2MSFTNGP10.phx.gbl...
> Your SQL should be in the Business Layer. The presentation layer should> not make or provide decisions on how data is collected ( that what tables> / view or columns are used ) as that is a business rule.
>
>
>
> "Jay Balapa" <jb*****@hotmail.com> wrote in message
> news:%2****************@tk2msftngp13.phx.gbl...
>> Hello,
>>
>> Currently my application has three tiers-
>>
>> 1. Presentation Layer (Asp.Net / Win Forms/ Pocket PC UI.)
>> This predominantly contains User Controls, Custom Controls and Win/Web>> Forms.
>> I have one base form and I inherit from that form.
>> All validation is done in this tier. There is zero Data Access code in
>> this tier. This tier exclusively gets DataViews/ Arays/Lists as input.>> Outputs are string objects with SQL Statements or just paremeters with
>> dataconnection key.
>>
>> 2. Business Layer.
>> Currently this is just a Library residing in the same machine as
>> Presentation layer. Eventually I plan to use WebServices if application>> needs physical seperation.
>> Most of Business Logic are implemented in this layer. There is
>> absolutely no UI code here.
>> These are all bunch of static methods which perform CRUD functionality.>> All methods are atomic in nature. I dont rely on Static Variables.
>> There is just one DatabaseGateway class which does all the
>> functionality.
>>
>> 3. Data Layer. (SQL Server)
>> I dont use stored procedures. predominantly use Views.
>>
>>
>> I have been reading up on Rockford Lhotka's business objects and I just>> feel that his framework is unnecessarily complex. I just dont see the
>> need to hold these intermediate Business Objects.
>>
>>
>>
>> Thanks for your responses.
>>
>> --
>> Jay Balapa
>> Director Of Software Engineering
>> www.atginc.com
>>
>>
>>
>>
>>
>
>

[Joerg Jooss]

Josh wrote:

Your SQL should be in the Business Layer. The presentation layer
should not make or provide decisions on how data is collected ( that
what tables / view or columns are used ) as that is a business rule.

SQL belongs in the Data Access Layer, not in the Business Layer. Why
tie the business logic to any specific persistence mechanism?
Cheers,
--
http://www.joergjooss.de
mailto:ne********@joergjooss.de

[William \(Bill\) Vaughn]

What? I would get your facts straight before advising people to simply
depend on C# for Stored Procedure coding. While it's entirely possible to
write stored procedures and other server-side executables in CLR languages
(including C# and VB.NET), it's not always (and not even usually) a good
idea to do so. CLR code execution should be reserved for a few specific
cases where CPU-intensive operations or those jobs that TSQL was never
designed to handle.
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
www.sqlreportingservices.net
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
"Eliyahu Goldin" <re*************@monarchmed.com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

With SQL Server 2005 you can write stored procedures etc. in c#.

Eliyahu

"Steve Walker" <st***@otolith.demon.co.uk> wrote in message
news:Iv**************@otolith.demon.co.uk...

In message <Xn**************************@127.0.0.1>, Chad Z. Hower aka
Kudzu <cp**@hower.org> writes

>"bradley" <so*****@microsoft.com> wrote in
>news:#9**************@TK2MSFTNGP15.phx.gbl:
>> If you want to do away with the complexity of the business objects,
>> then consider moving this business logic to the database as stored
>> procedures and triggers.
>
>There are of course many schools of thought, but personally I would
>never recommend that. If
>you want my views as to why, you can read the link that I just posted.

Agree. For one thing, TSQL is a horrible language to do anything
non-trivial in.

--
Steve Walker

[Chad Z. Hower aka Kudzu]

"Michael Rodriguez" <mi**@nospamforme.com> wrote in
news:#Q**************@TK2MSFTNGP10.phx.gbl:

It's really a very fine line. If you have a system where hundreds of
users are crunching loads of data, which poison do you pick? Do you
do all the work in stored procedures (= database bottleneck), or do
you send everything back to the clients and distribute the processing
(= network bottleneck). We're still trying to figure it out...

It depends on your system, and every sysetm is unique. No pattern will fit every system. What I
presented works well in my experience in 90%+ of systems. But each developer needs to evualate
the pattern and see if it is a good match for their system.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Blog: http://blogs.atozed.com/kudzu

[Chad Z. Hower aka Kudzu]

"William \(Bill\) Vaughn" <bi**********@betav.com> wrote in
news:uD**************@TK2MSFTNGP15.phx.gbl:

What? I would get your facts straight before advising people to simply
depend on C# for Stored Procedure coding. While it's entirely possible
to write stored procedures and other server-side executables in CLR
languages (including C# and VB.NET), it's not always (and not even
usually) a good idea to do so. CLR code execution should be reserved
for a few specific cases where CPU-intensive operations or those jobs
that TSQL was never designed to handle.

For code that exists on the database server, I agree. Im excited about where MS is going with this, but the
first generation of CLR on the DB I think is going to cause more problems as its not "complete" yet as
to where it will eventually go and be really useful, and in the interim users wont know the proper
roles and will abuse it.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Blog: http://blogs.atozed.com/kudzu

[Eliyahu Goldin]

Where did you find in my post any advice for anything? You yourself write
"it's entirely possible to write stored procedures and other server-side
executables in CLR languages (including C# and VB.NET)". That's what I have
said too, nothing more.

Eliyahu

"William (Bill) Vaughn" <bi**********@betav.com> wrote in message
news:uD**************@TK2MSFTNGP15.phx.gbl...

What? I would get your facts straight before advising people to simply
depend on C# for Stored Procedure coding. While it's entirely possible to
write stored procedures and other server-side executables in CLR languages
(including C# and VB.NET), it's not always (and not even usually) a good
idea to do so. CLR code execution should be reserved for a few specific
cases where CPU-intensive operations or those jobs that TSQL was never
designed to handle.
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
www.sqlreportingservices.net
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights. __________________________________
"Eliyahu Goldin" <re*************@monarchmed.com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

With SQL Server 2005 you can write stored procedures etc. in c#.

Eliyahu

"Steve Walker" <st***@otolith.demon.co.uk> wrote in message
news:Iv**************@otolith.demon.co.uk...

In message <Xn**************************@127.0.0.1>, Chad Z. Hower aka
Kudzu <cp**@hower.org> writes
>"bradley" <so*****@microsoft.com> wrote in
>news:#9**************@TK2MSFTNGP15.phx.gbl:
>> If you want to do away with the complexity of the business objects,
>> then consider moving this business logic to the database as stored
>> procedures and triggers.
>
>There are of course many schools of thought, but personally I would
>never recommend that. If
>you want my views as to why, you can read the link that I just posted.

Agree. For one thing, TSQL is a horrible language to do anything
non-trivial in.

--
Steve Walker

[WillemM]

Datasets are not SQL...
So if you need to iterate through dataset objects, that just fine.
But don't pass things like "SELECT * FROM Customers WHERE CustomerId = 1"
from the presentation layer into the business logic. Instead you should do
the following: DataSet customerData = bll.GetCustomer(1); in the presentation
layer

--
Best regards,

WillemM
"Eliyahu Goldin" wrote:

I am not sure what are you getting to by insisting on moving the SQL to the
business layer. It looks to me like insisting on the dotnet framework to
belong to one layer only.

A database consists of tables, view, stored procedures, triggers etc. Tables
and views belong to data layer. Stored procedures and triggers can be in
either data or business layer. It won't hurt the SQL server if it will
contain elements of both levels.

Eliyahu

"Josh" <[e-mail]> wrote in message
news:uG**************@tk2msftngp13.phx.gbl...

Keeping the layers truely seperate is difficult. I would suggest that

even

if you have to itereate through a result set the SQL should be in the
Business Layer, pass your filter criteria to the business layer.


"Jay Balapa" <jb*****@hotmail.com> wrote in message
news:eD*************@TK2MSFTNGP12.phx.gbl...

Josh,

Thanks for your response.

SQL most of the time is in the Business layer.

Sometimes I need to iterate Datarows in a Datagrid. In those cases I make that exception.

--
Jay
"Josh" <[e-mail]> wrote in message
news:OS**************@TK2MSFTNGP10.phx.gbl...
> Your SQL should be in the Business Layer. The presentation layer should> not make or provide decisions on how data is collected ( that what tables> / view or columns are used ) as that is a business rule.
>
>
>
> "Jay Balapa" <jb*****@hotmail.com> wrote in message
> news:%2****************@tk2msftngp13.phx.gbl...
>> Hello,
>>
>> Currently my application has three tiers-
>>
>> 1. Presentation Layer (Asp.Net / Win Forms/ Pocket PC UI.)
>> This predominantly contains User Controls, Custom Controls and Win/Web>> Forms.
>> I have one base form and I inherit from that form.
>> All validation is done in this tier. There is zero Data Access code in
>> this tier. This tier exclusively gets DataViews/ Arays/Lists as input.>> Outputs are string objects with SQL Statements or just paremeters with
>> dataconnection key.
>>
>> 2. Business Layer.
>> Currently this is just a Library residing in the same machine as
>> Presentation layer. Eventually I plan to use WebServices if application>> needs physical seperation.
>> Most of Business Logic are implemented in this layer. There is
>> absolutely no UI code here.
>> These are all bunch of static methods which perform CRUD functionality.>> All methods are atomic in nature. I dont rely on Static Variables.
>> There is just one DatabaseGateway class which does all the
>> functionality.
>>
>> 3. Data Layer. (SQL Server)
>> I dont use stored procedures. predominantly use Views.
>>
>>
>> I have been reading up on Rockford Lhotka's business objects and I just>> feel that his framework is unnecessarily complex. I just dont see the
>> need to hold these intermediate Business Objects.
>>
>>
>>
>> Thanks for your responses.
>>
>> --
>> Jay Balapa
>> Director Of Software Engineering
>> www.atginc.com
>>
>>
>>
>>
>>
>
>

[Mahesh]

I agree with it though, it's not the correct example.

In our case we need to pull the data from different tables, apply business
logic then pull data from other tables if required and insert in to
Temporary table then open cursor on Temporary table which returns data to
calling application.

Regards,
Mahesh

"Michael Rodriguez" wrote:

"Chad Z. Hower aka Kudzu" <cp**@hower.org> wrote in message
news:Xn**************************@127.0.0.1...

"bradley" <so*****@microsoft.com> wrote in
news:#9**************@TK2MSFTNGP15.phx.gbl:

If you want to do away with the complexity of the business objects,
then consider moving this business logic to the database as stored
procedures and triggers.

There are of course many schools of thought, but personally I would never
recommend that. If
you want my views as to why, you can read the link that I just posted.

Chad,

I have to respectively disagree with you. There are several instances where
the business logic should be in the stored procedures. Suppose you have a
posting procedure that needs to compute the average cost of items based on
thousands of invoices, then post those costs to another table. In order to
do that logic in the business tier, you would have to retrieve all of the
relevant data locally, crunch it, then send it back to the DB server in
another form. This defeats the whole purpose of having a database server to
begin with. Now you're back to the FoxPro days where the network bandwith
was sucked up by thousands and thousands of rows of data being sent back and
forth across the network for processing. One of the main advantages of
having a database server is to let it crunch (read - perform logic) all the
data and return only the much smaller result set.

I'm not saying your approach is necessarily incorrect. That would work
great if you were dealing with small chunks of data. But when you have to
insert values into tables based on numbers computed from thousands of rows
of data in other tables, I think it's best to let the DB server do all of
the work for you. That way nothing has to travel across a wire.

My $.02

Mike Rodriguez

[Chad Z. Hower aka Kudzu]

=?Utf-8?B?TWFoZXNo?= <Ma****@discussions.microsoft.com> wrote in
news:90**********************************@microsof t.com:

I agree with it though, it's not the correct example.

In our case we need to pull the data from different tables, apply
business logic then pull data from other tables if required and
insert in to Temporary table then open cursor on Temporary table which
returns data to calling application.

Which is the overwhelmingly common scenario. What I described will work very well for you.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Blog: http://blogs.atozed.com/kudzu

[Mahesh P]

Hi all;
Three tier architecture is very use ful for distributed application; You can
do one thing make some common classes for common functions and use sqlhelper
class as a DAL (Data Access Layer); dont customize sqlhelper class becauase
this can be use for all applications.
you can also customize your shared functions and pass sql statement as
string and can pass perameter according to condition; but you should use
stored procedure;
thankx

"Eliyahu Goldin" wrote:

Sometimes it is the best practice. You can change from one platform to
another without affecting the business logic implemented in stored
procedures.

Eliyahu

"Kim Quigley" <ki********@hotmail.com> wrote in message
news:%2******************@TK2MSFTNGP14.phx.gbl...

I wasn't aware that putting SQL in the business layer was a best practice.

I

use SQL Server 2000 with stored procedures and my data layer accesses

those

stored procedures. In the business layer, I have logical business objects
with properties and methods. The purpose of having a seperate data layer

is

so that if your data source changes (for example: moving from SQL Server

to

MySQL) then you only have to modify the data layer. The presentation and
business layers would be unaffected.
"Josh" <[e-mail]> wrote in message
news:OS**************@TK2MSFTNGP10.phx.gbl...

Your SQL should be in the Business Layer. The presentation layer should
not make or provide decisions on how data is collected ( that what tables / view or columns are used ) as that is a business rule.

"Jay Balapa" <jb*****@hotmail.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
> Hello,
>
> Currently my application has three tiers-
>
> 1. Presentation Layer (Asp.Net / Win Forms/ Pocket PC UI.)
> This predominantly contains User Controls, Custom Controls and Win/Web
> Forms.
> I have one base form and I inherit from that form.
> All validation is done in this tier. There is zero Data Access code in
> this tier. This tier exclusively gets DataViews/ Arays/Lists as input.
> Outputs are string objects with SQL Statements or just paremeters with
> dataconnection key.
>
> 2. Business Layer.
> Currently this is just a Library residing in the same machine as
> Presentation layer. Eventually I plan to use WebServices if application
> needs physical seperation.
> Most of Business Logic are implemented in this layer. There is absolutely> no UI code here.
> These are all bunch of static methods which perform CRUD functionality.
> All methods are atomic in nature. I dont rely on Static Variables. There> is just one DatabaseGateway class which does all the functionality.
>
> 3. Data Layer. (SQL Server)
> I dont use stored procedures. predominantly use Views.
>
>
> I have been reading up on Rockford Lhotka's business objects and I just
> feel that his framework is unnecessarily complex. I just dont see the
> need to hold these intermediate Business Objects.
>
>
>
> Thanks for your responses.
>
> --
> Jay Balapa
> Director Of Software Engineering
> www.atginc.com
>
>
>
>
>

[Tony Phillips]

I agree. I am don't believe in putting business logic inside of the
database. Business logic belongs in the Business Logic Layer (BLL). In
addition, SQL commands and data access code do not belong in the BLL. A
entity should never know how to persist itself in the database. This is why
I am not a fan of Lhotka's CSLA framework. This breaks classic object
oriented programming rules.

"Chad Z. Hower aka Kudzu" wrote:

"bradley" <so*****@microsoft.com> wrote in
news:#9**************@TK2MSFTNGP15.phx.gbl:

If you want to do away with the complexity of the business objects,
then consider moving this business logic to the database as stored
procedures and triggers.

There are of course many schools of thought, but personally I would never recommend that. If
you want my views as to why, you can read the link that I just posted.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Blog: http://blogs.atozed.com/kudzu

[Robbe Morris [C# MVP]]

This has served me pretty well as a base design for
the software families I work on:
--
Robbe Morris - 2004/2005 Microsoft MVP C#
EggHeadCafe's RSS Search Engine
http://www.eggheadcafe.com/articles/...h/default.aspx


"Tony Phillips" <Tony Ph******@discussions.microsoft.com> wrote in message
news:A0**********************************@microsof t.com...

I agree. I am don't believe in putting business logic inside of the
database. Business logic belongs in the Business Logic Layer (BLL). In
addition, SQL commands and data access code do not belong in the BLL. A
entity should never know how to persist itself in the database. This is
why
I am not a fan of Lhotka's CSLA framework. This breaks classic object
oriented programming rules.

"Chad Z. Hower aka Kudzu" wrote:

"bradley" <so*****@microsoft.com> wrote in
news:#9**************@TK2MSFTNGP15.phx.gbl:

> If you want to do away with the complexity of the business objects,
> then consider moving this business logic to the database as stored
> procedures and triggers.

There are of course many schools of thought, but personally I would never
recommend that. If
you want my views as to why, you can read the link that I just posted.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Blog: http://blogs.atozed.com/kudzu

[Robbe Morris [C# MVP]]

http://www.eggheadcafe.com/articles/...plications.asp

--
Robbe Morris - 2004/2005 Microsoft MVP C#
EggHeadCafe's RSS Search Engine
http://www.eggheadcafe.com/articles/...h/default.aspx


"Tony Phillips" <Tony Ph******@discussions.microsoft.com> wrote in message
news:A0**********************************@microsof t.com...

I agree. I am don't believe in putting business logic inside of the
database. Business logic belongs in the Business Logic Layer (BLL). In
addition, SQL commands and data access code do not belong in the BLL. A
entity should never know how to persist itself in the database. This is
why
I am not a fan of Lhotka's CSLA framework. This breaks classic object
oriented programming rules.

"Chad Z. Hower aka Kudzu" wrote:

"bradley" <so*****@microsoft.com> wrote in
news:#9**************@TK2MSFTNGP15.phx.gbl:

> If you want to do away with the complexity of the business objects,
> then consider moving this business logic to the database as stored
> procedures and triggers.

There are of course many schools of thought, but personally I would never
recommend that. If
you want my views as to why, you can read the link that I just posted.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Blog: http://blogs.atozed.com/kudzu

[Kevin Spencer]

Pretty good stuff, Robbe!

--

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

"Robbe Morris [C# MVP]" <in**@eggheadcafe.com> wrote in message
news:Oz**************@TK2MSFTNGP09.phx.gbl...

http://www.eggheadcafe.com/articles/...plications.asp

--
Robbe Morris - 2004/2005 Microsoft MVP C#
EggHeadCafe's RSS Search Engine
http://www.eggheadcafe.com/articles/...h/default.aspx


"Tony Phillips" <Tony Ph******@discussions.microsoft.com> wrote in message
news:A0**********************************@microsof t.com...

I agree. I am don't believe in putting business logic inside of the
database. Business logic belongs in the Business Logic Layer (BLL). In
addition, SQL commands and data access code do not belong in the BLL. A
entity should never know how to persist itself in the database. This is
why
I am not a fan of Lhotka's CSLA framework. This breaks classic object
oriented programming rules.

"Chad Z. Hower aka Kudzu" wrote:

"bradley" <so*****@microsoft.com> wrote in
news:#9**************@TK2MSFTNGP15.phx.gbl:
> If you want to do away with the complexity of the business objects,
> then consider moving this business logic to the database as stored
> procedures and triggers.

There are of course many schools of thought, but personally I would
never recommend that. If
you want my views as to why, you can read the link that I just posted.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Blog: http://blogs.atozed.com/kudzu