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*****@hotmai l.com> wrote in message
news:%2******** ********@tk2msf tngp13.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******** ******@TK2MSFTN GP10.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*****@hotmai l.com> wrote in message
news:%2******** ********@tk2msf tngp13.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*****@hotmai l.com> wrote in message
news:%2******** ********@tk2msf tngp13.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*****@hotmai l.com> wrote in message
news:eD******** *****@TK2MSFTNG P12.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******** ******@TK2MSFTN GP10.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*****@hotmai l.com> wrote in message
news:%2******** ********@tk2msf tngp13.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******** ******@TK2MSFTN GP10.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*****@hotmai l.com> wrote in message
news:%2******** ********@tk2msf tngp13.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*****@hotmai l.com> wrote in
news:#z******** ******@tk2msftn gp13.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/
"Programmin g is an art form that fights back"

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

[Chad Z. Hower aka Kudzu]

"Jay Balapa" <jb*****@hotmai l.com> wrote in
news:#z******** ******@tk2msftn gp13.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/
"Programmin g is an art form that fights back"

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

[Chad Z. Hower aka Kudzu]

"Kim Quigley" <ki********@hot mail.com> wrote in
news:#n******** ******@TK2MSFTN GP14.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/
"Programmin g is an art form that fights back"

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

[Chad Z. Hower aka Kudzu]

"bradley" <so*****@micros oft.com> wrote in
news:#9******** ******@TK2MSFTN GP15.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/
"Programmin g is an art form that fights back"

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