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

[Chad Z. Hower aka Kudzu]

"William \(Bill\) Vaughn" <bi**********@b etav.com> wrote in
news:uD******** ******@TK2MSFTN GP15.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/
"Programmin g 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**********@b etav.com> wrote in message
news:uD******** ******@TK2MSFTN GP15.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.co m> wrote in message
news:%2******** ********@TK2MSF TNGP15.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*****@micros oft.com> wrote in
>news:#9******* *******@TK2MSFT NGP15.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******** ******@tk2msftn gp13.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*****@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
>>
>>
>>
>>
>>
>
>

[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*****@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,

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****@discuss ions.microsoft. com> wrote in
news:90******** *************** ***********@mic rosoft.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/
"Programmin g 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********@hot mail.com> wrote in message
news:%2******** **********@TK2M SFTNGP14.phx.gb l...

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
>
>
>
>
>

[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*****@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

[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******@discus sions.microsoft .com> wrote in message
news:A0******** *************** ***********@mic rosoft.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*****@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

[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******@discus sions.microsoft .com> wrote in message
news:A0******** *************** ***********@mic rosoft.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*****@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

[Kevin Spencer]

Pretty good stuff, Robbe!

--

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

"Robbe Morris [C# MVP]" <in**@eggheadca fe.com> wrote in message
news:Oz******** ******@TK2MSFTN GP09.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******@discus sions.microsoft .com> wrote in message
news:A0******** *************** ***********@mic rosoft.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*****@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