Hello Scott!



At first, I was actually quite astonished to see the speed of ADODB. 

However, having given it a few thoughts I came to the conclusion you've 

read and agree on. Which brings me to another question. When moving to 

the true n-tier application, I am a little unsure what the datalayer 

exactly is supposed to do.



Question:

Should the datalayer for instance make sure to delete rows from related 

tables

when a delete command was issued?! Or, should the datalayer just execute 

the stored procedure from the data and then rely on the stored procedure 

to keep the tabledata consistent?! To be honents, I'd chose the latter - 

having the datalayer to execute the stored procedure and then make all 

the consistencywork in the stored procedure.



Which is your approach? Please share your experience!



For instance, in my current application (I'm about to finish the 

database design), I have the following tiers:



1. data (SQL Server - everything is handled through stored procedures. 

Selects, inserts, updates and deletes)



2. data-layer (C# components)



3. business-layer (ASP.NET w. C#)

Prohibited from using custom SQL to the data thus bypassing the 

datalayer.



4. presentation-layer (ASP.NET w. C#)

Prohibited too from using custom SQL to the data thus bypassing the 

datalayer.



Basically, step 3 and 4 are tied together in the ASP.NET framework 

(mostly representated as a index.aspx file which *imports* the datalayer 

namespaces and *includes* a non-compiled include-file (using the include 

directive) containing the 'codebehind' code for each page-module. This 

basically gives the freedom of traditional rapid ASP development, where 

you always have your datalayer available by importing the namespace in 

your file (you would always want to have it instantly available as 

bypassing the datalayer from the 3rd and 4th tier is a no-no).



Why:

I decided on this approach because I wanted to limit the amount of 

components residing in the /bin directory - only the datalayer 

programmers should work in that directory - and IF a business-layer or 

presentation-layer programmer need extra data-access, they'd have to 

resolve this with the datalayer programmers.



Another reason to keep the the /bin directory from being flodded with 

components is that in a multi-user development team, the risk of a 

programmer to overwrite/delete one of your components is much higher 

than if the programmer was working on a set of files in his/her own 

sub-directory.



With Regards

Anders Lundholm - lundholm@s...

--

I replay to this message because of my 3 years experince in building Windows

DNA solutions..



If we look at a 3-tier solution in a distributed application, we have:



1. Presentation ( Win32, ASP )

2. Business Object ( COM/COM+ )

3. Data ( SQL server )



3. If we start with the Data layer we have for example a database ( SQL

Server )

   To increase perfomance we use Store procedure to select, delete, update

and insert data to the database.



2. If we look at the Business layer we have the objects.

   Here we use Component services to handle transactions etc.

   It's importent to split the business logic and the data from each other.

   So we say we have two services or layers here.



	1. Business

	2. Data-access



   The data-access objects need to know its data source, for example SQL

Server 7.

   We Use ADO.NET with the SQL... classes.

   We make the connection and execute queries such as Store procedures and

return a DataSet or DataReader

   to the Business services.



   The business objects should not know where the data comes from. It's way

we have the

   Data-access services, and it's very simple to move the data object or

change it if we use other

   databases without changing the busniess objects.



1. We can use ASP pages or Win32 to call a function from a Business object.

   This layer should only display data, try to move busniess logic from this

layer to the

   business layer if it's possible, sometimes is not possible or sometimes

is better to have some business

   logic in the presentation layer to increase performance.



In the .Net framwork we have some more technologies to use.

For example if we want to use Object pooling, transactions, connection

pooling, we can create COM+ components in the .Net framework and use the

COM+ services with the CLR. This is very easy done.

We have more flexibility with the .Net, because of the OO languages we can

think in more OO terms.

A very good example to look at is "Fitch and Mathers" for the .Net

framework.

I promise you we will have use of it, IBuySpy is a good example too.



/Fredrik Normén

( MSCD - Microsoft Certified Solution Developer )













-----Original Message-----

From: Anders Lundholm [mailto:lundholm@s...]

Sent: den 28 november 2000 12:07

To: ASP+

Subject: [aspx] SQLConnection speed vs. ADODB.Connection - Tier design!





Hello Scott!



At first, I was actually quite astonished to see the speed of ADODB.

However, having given it a few thoughts I came to the conclusion you've read

and agree on. Which brings me to another question. When moving to the true

n-tier application, I am a little unsure what the datalayer exactly is

supposed to do.



Question:

Should the datalayer for instance make sure to delete rows from related

tables

when a delete command was issued?! Or, should the datalayer just execute the

stored procedure from the data and then rely on the stored procedure to keep

the tabledata consistent?! To be honents, I'd chose the latter - having the

datalayer to execute the stored procedure and then make all the

consistencywork in the stored procedure.



Which is your approach? Please share your experience!



For instance, in my current application (I'm about to finish the database

design), I have the following tiers:



1. data (SQL Server - everything is handled through stored procedures.

Selects, inserts, updates and deletes)



2. data-layer (C# components)



3. business-layer (ASP.NET w. C#)

Prohibited from using custom SQL to the data thus bypassing the datalayer.



4. presentation-layer (ASP.NET w. C#)

Prohibited too from using custom SQL to the data thus bypassing the

datalayer.



Basically, step 3 and 4 are tied together in the ASP.NET framework (mostly

representated as a index.aspx file which *imports* the datalayer namespaces

and *includes* a non-compiled include-file (using the include directive)

containing the 'codebehind' code for each page-module. This basically gives

the freedom of traditional rapid ASP development, where you always have your

datalayer available by importing the namespace in your file (you would

always want to have it instantly available as bypassing the datalayer from

the 3rd and 4th tier is a no-no).



Why:

I decided on this approach because I wanted to limit the amount of

components residing in the /bin directory - only the datalayer programmers

should work in that directory - and IF a business-layer or

presentation-layer programmer need extra data-access, they'd have to resolve

this with the datalayer programmers.



Another reason to keep the the /bin directory from being flodded with

components is that in a multi-user development team, the risk of a

programmer to overwrite/delete one of your components is much higher than if

the programmer was working on a set of files in his/her own sub-directory.



With Regards

Anders Lundholm - lundholm@s...

--

Fredrik,



You indicate that "we can create COM+ components in the .Net framework

and use the

COM+ services with the CLR".  Do you have any example vb7 code which

does this?



-----Original Message-----

From: Fredrik Norm=E9n [mailto:fredrik.normen@e...]

Sent: Tuesday, November 28, 2000 9:40 AM

To: ASP+

Subject: [aspx] RE: SQLConnection speed vs. ADODB.Connection - Tier

design!





I replay to this message because of my 3 years experince in building

Windows

DNA solutions..



If we look at a 3-tier solution in a distributed application, we have:



1. Presentation ( Win32, ASP )

2. Business Object ( COM/COM+ )

3. Data ( SQL server )



3. If we start with the Data layer we have for example a database ( SQL

Server )

   To increase perfomance we use Store procedure to select, delete,

update

and insert data to the database.



2. If we look at the Business layer we have the objects.

   Here we use Component services to handle transactions etc.

   It's importent to split the business logic and the data from each

other.

   So we say we have two services or layers here.



	1. Business

	2. Data-access



   The data-access objects need to know its data source, for example SQL

Server 7.

   We Use ADO.NET with the SQL... classes.

   We make the connection and execute queries such as Store procedures

and

return a DataSet or DataReader

   to the Business services.



   The business objects should not know where the data comes from. It's

way

we have the

   Data-access services, and it's very simple to move the data object or

change it if we use other

   databases without changing the busniess objects.



1. We can use ASP pages or Win32 to call a function from a Business

object.

   This layer should only display data, try to move busniess logic from

this

layer to the

   business layer if it's possible, sometimes is not possible or

sometimes

is better to have some business

   logic in the presentation layer to increase performance.



In the .Net framwork we have some more technologies to use.

For example if we want to use Object pooling, transactions, connection

pooling, we can create COM+ components in the .Net framework and use the

COM+ services with the CLR. This is very easy done.

We have more flexibility with the .Net, because of the OO languages we

can

think in more OO terms.

A very good example to look at is "Fitch and Mathers" for the .Net

framework.

I promise you we will have use of it, IBuySpy is a good example too.



/Fredrik Norm=E9n

( MSCD - Microsoft Certified Solution Developer )













-----Original Message-----

From: Anders Lundholm [mailto:lundholm@s...]

Sent: den 28 november 2000 12:07

To: ASP+

Subject: [aspx] SQLConnection speed vs. ADODB.Connection - Tier design!





Hello Scott!



At first, I was actually quite astonished to see the speed of ADODB.

However, having given it a few thoughts I came to the conclusion you've

read

and agree on. Which brings me to another question. When moving to the

true

n-tier application, I am a little unsure what the datalayer exactly is

supposed to do.



Question:

Should the datalayer for instance make sure to delete rows from related

tables

when a delete command was issued?! Or, should the datalayer just execute

the

stored procedure from the data and then rely on the stored procedure to

keep

the tabledata consistent?! To be honents, I'd chose the latter - having

the

datalayer to execute the stored procedure and then make all the

consistencywork in the stored procedure.



Which is your approach? Please share your experience!



For instance, in my current application (I'm about to finish the

database

design), I have the following tiers:



1. data (SQL Server - everything is handled through stored procedures.

Selects, inserts, updates and deletes)



2. data-layer (C# components)



3. business-layer (ASP.NET w. C#)

Prohibited from using custom SQL to the data thus bypassing the

datalayer.



4. presentation-layer (ASP.NET w. C#)

Prohibited too from using custom SQL to the data thus bypassing the

datalayer.



Basically, step 3 and 4 are tied together in the ASP.NET framework

(mostly

representated as a index.aspx file which *imports* the datalayer

namespaces

and *includes* a non-compiled include-file (using the include directive)

containing the 'codebehind' code for each page-module. This basically

gives

the freedom of traditional rapid ASP development, where you always have

your

datalayer available by importing the namespace in your file (you would

always want to have it instantly available as bypassing the datalayer

from

the 3rd and 4th tier is a no-no).



Why:

I decided on this approach because I wanted to limit the amount of

components residing in the /bin directory - only the datalayer

programmers

should work in that directory - and IF a business-layer or

presentation-layer programmer need extra data-access, they'd have to

resolve

this with the datalayer programmers.



Another reason to keep the the /bin directory from being flodded with

components is that in a multi-user development team, the risk of a

programmer to overwrite/delete one of your components is much higher

than if

the programmer was working on a set of files in his/her own

sub-directory.



With Regards

Anders Lundholm - lundholm@s...

--

Frederik, thanks for the lesson on DNA.  You are following the 

hard-core classic approach to an n-tier solution.  It's not always best 

for performance, for the reasons that I have already stated.



In addition, you said that you are passing a DataReader or DataSet back 

to your business layer, which is in no way separation from the 

data-layer.



I didn't want to go this deep into it, but in actuality what we have 

done is created a data layer object called IpDataConnection.  In our 

busines layer, we construct that object.  The constructor of that 

object opens a connection to our database and retains the open 

connection in a SQLConnection member variable.  It is this object that 

we then pass between the business layer components and data-layer 

components (which by the way have absolutely no hard-coded SQL 

statements EVERYTHING is in Stored Procedures as it should always be).  

The business layer NEVER sees anything to do with the actual data 

source.  The business layer components access any data that they need 

through members of the data-layer components (i.e. ArrayList, string, 

int, etc...)  Thereby further distancing themselves from the 

datasource.  The only difference is, I only have to create one 

connection and open it one time and close it one time.



Our pages are blazingly fast because our data access is very fast.





-----Original Message-----

From: Fredrik Norm=E9n [mailto:fredrik.normen@e...]

Sent: Tuesday, November 28, 2000 8:40 AM

To: ASP+

Subject: [aspx] RE: SQLConnection speed vs. ADODB.Connection - Tier

design!





I replay to this message because of my 3 years experince in building 

Windows

DNA solutions..



If we look at a 3-tier solution in a distributed application, we have:



1. Presentation ( Win32, ASP )

2. Business Object ( COM/COM+ )

3. Data ( SQL server )



3. If we start with the Data layer we have for example a database ( SQL

Server )

   To increase perfomance we use Store procedure to select, delete, 

update

and insert data to the database.



2. If we look at the Business layer we have the objects.

   Here we use Component services to handle transactions etc.

   It's importent to split the business logic and the data from each 

other.

   So we say we have two services or layers here.



	1. Business

	2. Data-access



   The data-access objects need to know its data source, for example 

SQL

Server 7.

   We Use ADO.NET with the SQL... classes.

   We make the connection and execute queries such as Store procedures 

and

return a DataSet or DataReader

   to the Business services.



   The business objects should not know where the data comes from. It's 

way

we have the

   Data-access services, and it's very simple to move the data object 

or

change it if we use other

   databases without changing the busniess objects.



1. We can use ASP pages or Win32 to call a function from a Business 

object.

   This layer should only display data, try to move busniess logic from 

this

layer to the

   business layer if it's possible, sometimes is not possible or 

sometimes

is better to have some business

   logic in the presentation layer to increase performance.



In the .Net framwork we have some more technologies to use.

For example if we want to use Object pooling, transactions, connection

pooling, we can create COM+ components in the .Net framework and use 

the

COM+ services with the CLR. This is very easy done.

We have more flexibility with the .Net, because of the OO languages we 

can

think in more OO terms.

A very good example to look at is "Fitch and Mathers" for the .Net

framework.

I promise you we will have use of it, IBuySpy is a good example too.



/Fredrik Norm=E9n

( MSCD - Microsoft Certified Solution Developer )













-----Original Message-----

From: Anders Lundholm [mailto:lundholm@s...]

Sent: den 28 november 2000 12:07

To: ASP+

Subject: [aspx] SQLConnection speed vs. ADODB.Connection - Tier design!





Hello Scott!



At first, I was actually quite astonished to see the speed of ADODB.

However, having given it a few thoughts I came to the conclusion you've 

read

and agree on. Which brings me to another question. When moving to the 

true

n-tier application, I am a little unsure what the datalayer exactly is

supposed to do.



Question:

Should the datalayer for instance make sure to delete rows from related

tables

when a delete command was issued?! Or, should the datalayer just 

execute the

stored procedure from the data and then rely on the stored procedure to 

keep

the tabledata consistent?! To be honents, I'd chose the latter - having 

the

datalayer to execute the stored procedure and then make all the

consistencywork in the stored procedure.



Which is your approach? Please share your experience!



For instance, in my current application (I'm about to finish the 

database

design), I have the following tiers:



1. data (SQL Server - everything is handled through stored procedures.

Selects, inserts, updates and deletes)



2. data-layer (C# components)



3. business-layer (ASP.NET w. C#)

Prohibited from using custom SQL to the data thus bypassing the 

datalayer.



4. presentation-layer (ASP.NET w. C#)

Prohibited too from using custom SQL to the data thus bypassing the

datalayer.



Basically, step 3 and 4 are tied together in the ASP.NET framework 

(mostly

representated as a index.aspx file which *imports* the datalayer 

namespaces

and *includes* a non-compiled include-file (using the include 

directive)

containing the 'codebehind' code for each page-module. This basically 

gives

the freedom of traditional rapid ASP development, where you always have 

your

datalayer available by importing the namespace in your file (you would

always want to have it instantly available as bypassing the datalayer 

from

the 3rd and 4th tier is a no-no).



Why:

I decided on this approach because I wanted to limit the amount of

components residing in the /bin directory - only the datalayer 

programmers

should work in that directory - and IF a business-layer or

presentation-layer programmer need extra data-access, they'd have to 

resolve

this with the datalayer programmers.



Another reason to keep the the /bin directory from being flodded with

components is that in a multi-user development team, the risk of a

programmer to overwrite/delete one of your components is much higher 

than if

the programmer was working on a set of files in his/her own 

sub-directory.



With Regards

Anders Lundholm - lundholm@s...

--











---

Wrox Professional Web Developer Conference II

http://www.wroxconferences.com/WebDevEurope

November 29th - December 1st 2000, Amsterdam, Netherlands

Create powerful distributed web applications serving you now and

in the future. From ASP+ and VB.NET to XML and SQL Server 2000

Anders,

You are following the same path that we have chosen.  So our approach is 

very similar to what you have mentioned.  It is working great for us.



You should keep as much stuff in stored procedures as possible.  Even simple select statements.



Scott Davis

MCSD, MCP

International Parts

Decision Consultants Inc.





-----Original Message-----

From: Anders Lundholm [mailto:lundholm@s...]

Sent: Tuesday, November 28, 2000 6:07 AM

To: ASP+

Subject: [aspx] SQLConnection speed vs. ADODB.Connection - Tier design!





Hello Scott!



At first, I was actually quite astonished to see the speed of ADODB. 

However, having given it a few thoughts I came to the conclusion you've 

read and agree on. Which brings me to another question. When moving to the 

true n-tier application, I am a little unsure what the datalayer exactly 

is supposed to do.



Question:

Should the datalayer for instance make sure to delete rows from related 

tables 



when a delete command was issued?! Or, should the datalayer just execute 

the stored procedure from the data and then rely on the stored procedure 

to keep the tabledata consistent?! To be honents, I'd chose the latter - 

having the datalayer to execute the stored procedure and then make all the 

consistencywork in the stored procedure.



Which is your approach? Please share your experience!



For instance, in my current application (I'm about to finish the database 

design), I have the following tiers:



1. data (SQL Server - everything is handled through stored procedures. Selects, inserts, updates and deletes)



2. data-layer (C# components)



3. business-layer (ASP.NET w. C#)

Prohibited from using custom SQL to the data thus bypassing the datalayer.



4. presentation-layer (ASP.NET w. C#)

Prohibited too from using custom SQL to the data thus bypassing the 

datalayer.



Basically, step 3 and 4 are tied together in the ASP.NET framework (mostly 

representated as a index.aspx file which *imports* the datalayer 

namespaces and *includes* a non-compiled include-file (using the include 

directive) containing the 'codebehind' code for each page-module. This 

basically gives the freedom of traditional rapid ASP development, where 

you always have your datalayer available by importing the namespace in 

your file (you would always want to have it instantly available as 

bypassing the datalayer from the 3rd and 4th tier is a no-no).



Why:

I decided on this approach because I wanted to limit the amount of 

components residing in the /bin directory - only the datalayer programmers 

should work in that directory - and IF a business-layer or presentation-

layer programmer need extra data-access, they'd have to resolve this with 

the datalayer programmers.



Another reason to keep the the /bin directory from being flodded with 

components is that in a multi-user development team, the risk of a 

programmer to overwrite/delete one of your components is much higher than 

if the programmer was working on a set of files in his/her own sub-

directory.



With Regards

Anders Lundholm - lundholm@s...

--

>In addition, you said that you are passing a DataReader or DataSet back to

your business layer, which is in no >way separation from the data-layer.



Even if I retun a dataset or a datareader or other objects, the busniess

object doesn't know where the data cames from. In your place I should try to

use object pooling and see if that will increase or have the same

performance that you have now. What I understand from your text is that, you

open a connection and pass it to other object. I think you can increase your

performance by removing this passing and instead using Object pooling. Or do

you have allready try this ?



>object that we then pass between the business layer components and

data-layer components (which by the way have >absolutely no hard-coded SQL

statements EVERYTHING is in Stored Procedures as it should always be).



Sometimes a simple SQL query passed to the SQL server can be faster or have

the same profromance like an SP.

If you in the future need to use an oracle database you will have some

problem to change all of you SQL Server SP to oracle SP, becuase Store

procedure is not a ansi-sql standard.

I like SP! And use it allmost everywhere, becuase of performance and to have

an easy way to change the SQL queries without compiling the objects. But I'm

aware of some problems if I have a customer that want to use an oracle

database instead of SQL Server.



>The business layer NEVER sees anything to do with the actual data source.

The business layer components access >any data that they need through

members of the data-layer components (i.e. ArrayList, string, int, etc...)

>Thereby further distancing themselves from the datasource.  The only

difference is, I only have to create one

>connection and open it one time and close it one time.



Do you mean when you are calling many functions in a busniess object and the

functions need to open a connection ? Or do you open a connection for every

users and hold it there ?



/Fredrik Normén





-----Original Message-----

From: Fredrik Normén [mailto:fredrik.normen@e...]

Sent: Tuesday, November 28, 2000 8:40 AM

To: ASP+

Subject: [aspx] RE: SQLConnection speed vs. ADODB.Connection - Tier

design!





I replay to this message because of my 3 years experince in building Windows

DNA solutions..



If we look at a 3-tier solution in a distributed application, we have:



1. Presentation ( Win32, ASP )

2. Business Object ( COM/COM+ )

3. Data ( SQL server )



3. If we start with the Data layer we have for example a database ( SQL

Server )

   To increase perfomance we use Store procedure to select, delete, update

and insert data to the database.



2. If we look at the Business layer we have the objects.

   Here we use Component services to handle transactions etc.

   It's importent to split the business logic and the data from each other.

   So we say we have two services or layers here.



	1. Business

	2. Data-access



   The data-access objects need to know its data source, for example SQL

Server 7.

   We Use ADO.NET with the SQL... classes.

   We make the connection and execute queries such as Store procedures and

return a DataSet or DataReader

   to the Business services.



   The business objects should not know where the data comes from. It's way

we have the

   Data-access services, and it's very simple to move the data object or

change it if we use other

   databases without changing the busniess objects.



1. We can use ASP pages or Win32 to call a function from a Business object.

   This layer should only display data, try to move busniess logic from this

layer to the

   business layer if it's possible, sometimes is not possible or sometimes

is better to have some business

   logic in the presentation layer to increase performance.



In the .Net framwork we have some more technologies to use.

For example if we want to use Object pooling, transactions, connection

pooling, we can create COM+ components in the .Net framework and use the

COM+ services with the CLR. This is very easy done.

We have more flexibility with the .Net, because of the OO languages we can

think in more OO terms.

A very good example to look at is "Fitch and Mathers" for the .Net

framework.

I promise you we will have use of it, IBuySpy is a good example too.



/Fredrik Normén

( MSCD - Microsoft Certified Solution Developer )













-----Original Message-----

From: Anders Lundholm [mailto:lundholm@s...]

Sent: den 28 november 2000 12:07

To: ASP+

Subject: [aspx] SQLConnection speed vs. ADODB.Connection - Tier design!





Hello Scott!



At first, I was actually quite astonished to see the speed of ADODB.

However, having given it a few thoughts I came to the conclusion you've read

and agree on. Which brings me to another question. When moving to the true

n-tier application, I am a little unsure what the datalayer exactly is

supposed to do.



Question:

Should the datalayer for instance make sure to delete rows from related

tables

when a delete command was issued?! Or, should the datalayer just execute the

stored procedure from the data and then rely on the stored procedure to keep

the tabledata consistent?! To be honents, I'd chose the latter - having the

datalayer to execute the stored procedure and then make all the

consistencywork in the stored procedure.



Which is your approach? Please share your experience!



For instance, in my current application (I'm about to finish the database

design), I have the following tiers:



1. data (SQL Server - everything is handled through stored procedures.

Selects, inserts, updates and deletes)



2. data-layer (C# components)



3. business-layer (ASP.NET w. C#)

Prohibited from using custom SQL to the data thus bypassing the datalayer.



4. presentation-layer (ASP.NET w. C#)

Prohibited too from using custom SQL to the data thus bypassing the

datalayer.



Basically, step 3 and 4 are tied together in the ASP.NET framework (mostly

representated as a index.aspx file which *imports* the datalayer namespaces

and *includes* a non-compiled include-file (using the include directive)

containing the 'codebehind' code for each page-module. This basically gives

the freedom of traditional rapid ASP development, where you always have your

datalayer available by importing the namespace in your file (you would

always want to have it instantly available as bypassing the datalayer from

the 3rd and 4th tier is a no-no).



Why:

I decided on this approach because I wanted to limit the amount of

components residing in the /bin directory - only the datalayer programmers

should work in that directory - and IF a business-layer or

presentation-layer programmer need extra data-access, they'd have to resolve

this with the datalayer programmers.



Another reason to keep the the /bin directory from being flodded with

components is that in a multi-user development team, the risk of a

programmer to overwrite/delete one of your components is much higher than if

the programmer was working on a set of files in his/her own sub-directory.



With Regards

Anders Lundholm - lundholm@s...

--

Hello Scott!



> You are following the same path that we have chosen.  So our approach is

> very similar to what you have mentioned.  It is working great for us.



It just depends upon what kind of application you're doing. Basically we've

just realized that for ASP.NET/C# it's very important to have fast-fast-fast

database access and as opening a DB connection has been proven to be slow

(atleast at present state - beta 1), we've chosen to keep the overhead as

little as possible.



> You should keep as much stuff in stored procedures as possible.  Even

simple select statements.



Yes, I always do. Can't stand to see production websites using inline SQL ..



with regards

anders lundholm ˇ lundholm@s...

the sphereworx / monoliner experience

--

Hello!



>Frederik, thanks for the lesson on DNA.  You are following the hard-core

classic

>approach to an n-tier solution.  It's not always best for performance, for

>the reasons that I have already stated.



Agree.



>In addition, you said that you are passing a DataReader or DataSet back to

>your business layer, which is in no way separation from the data-layer.



I don't agree here. Why would it be a bad approach to have the datalayer

return a DataReader or DataSet?! (I can see a point with datasets as they're

heavier than DataReaders, but one could provide two different functions ..

one for the DataReader and one for the DataSet).



Note: I owe to tell that I have merged the businesslayer with the

presentation layer for my application, as I have no secret formulas to hide.

In my oppinion, the need for a seperate businesslayer for most ASP.NET (and

older ASP) applications is overrated, because you just throw in another tier

which basically just hands over data from one layer to another - without

doing anything to it -> overhead.



Afaik, few pages on websites feature secret business-logic (well, CC

validation and such are examples). Mostly, it's about wrapping design around

database content - which is nice too, but I don't think a business-layer

needs to be introduced to achieve that. Again, your situation may be

different than mine here (my company).



Perhaps I'm missing the point or you haven't been using the datalayer to

pass back a DataReader with e.g. a navigation-structure (but I doubt it). Or

perhaps we're both missing each-others point! =o)



How would I pass back a navigation-structure to the presentation-layer

(which, in my oppinion is where the transformation of data to presentation

is made)?! Why would the SQLDataReader be bad design?



My approach:



1. buss. layer/pres. layer asks the datalayer for a navigtion-structure

(with params) and supplies a connection (and possible a fresh

SQLDataReader).

2. the datalayer asks the data (SQL Server) for the correct rows depending

upon the parameters supplied by the buss. layer/pres. layer (step one).

3. data from the SQL Server is passed back to the datalayer (effectively

handled as type SQLDataReader).

4. the datalayer hands over the SQLDataReader to the buss. layer/pres.

layer.

5. the buss. layer/pres. layer wraps the design around the SQLDataReader and

disposes the SQLDataReader.



I feel that your approach between step one and two is different. Are you

passing back arrays or something?!



Thanks in advance. I could use some light here before starting to build the

first big ASP.NET application!



with regards

anders lundholm ˇ lundholm@s...

the sphereworx / monoliner experience

--

>In addition, you said that you are passing a DataReader or DataSet back to

>your business layer, which is in no way separation from the data-layer.



>>I don't agree here. Why would it be a bad approach to have the datalayer

>>return a DataReader or DataSet?! (I can see a point with datasets as they're

>>heavier than DataReaders, but one could provide two different functions ..

>>one for the DataReader and one for the DataSet).



I didn't really mean that it was a bad approach.  I just stated that in my 

opinion, that's no different than passing a Connection into the Data-

Layer.  You would have to determine whether or not to pass back an 

ADODataReader or a SQLDataReader.  You'd be better off passing back 

DataSets, but then you lose the performance gain of the Readers.  Not to 

mention that DataSets aren't as easy to work with.



Perhaps I should have stated much earlier on that I am not DIRECTLY 

passing around a SQLConnection or ADOConnection, but instead an object 

that encapsulates those and hides all of the details of the connection 

from my business layer.  Therefore, my business layer is never affected by 

any changes in my data-layer.



>>My approach:



>>1. buss. layer/pres. layer asks the datalayer for a navigtion-structure

>>(with params) and supplies a connection (and possible a fresh

>>SQLDataReader).

>>2. the datalayer asks the data (SQL Server) for the correct rows depending

>>upon the parameters supplied by the buss. layer/pres. layer (step one).

>>3. data from the SQL Server is passed back to the datalayer (effectively

>>handled as type SQLDataReader).

>>4. the datalayer hands over the SQLDataReader to the buss. layer/pres.

>>layer.

>>5. the buss. layer/pres. layer wraps the design around the SQLDataReader and

>>disposes the SQLDataReader.



>>I feel that your approach between step one and two is different. Are you

>>passing back arrays or something?!



We aren't passing arrays.  Here is a simple example.  Let's say we have a 

CShopper object.  A Shopper can have multiple addresses.  The Shopper 

object would have an ArrayList member called Addresses, which will be a 

collection of CAddress objects  There would be a method on the CShopper 

object called GetAddresses().  GetAddresses would make call to the 

database to get the addresses for this shopper and return them in a 

SQLDataReader.  It would then loop through the SQLDataReader creating new 

CAddress objects.  The CAddress objects would be created by passing the 

SQLDataReader into the constructor of CAddress, which would populate 

itself from the DataReader.



After all of this happens, our business layer accesses the Shopper's 

Addresses through the ArrayList member of Addresses.  The business layer 

is completely separated from knowing anything about a Database.  All it 

knows is that it called GetAddresses() and then is able to retrieve the 

addresses through the Shopper's Addresses collection.



I've left out a ton of details, so don't start trying to tear this example 

apart.

>Perhaps I should have stated much earlier on that I am not DIRECTLY

>passing around a SQLConnection or ADOConnection, but instead an object

>that encapsulates those and hides all of the details of the connection

>from my business layer.  Therefore, my business layer is never affected by

>any changes in my data-layer.



Have you read the mail regarding how to use connection pooling with

SQLConnection, if not here is a

 brief summary:



<SNAP>

To deploy high-performance applications, you need to use connection pooling.

When you use the ADO Managed Provider you do not need to enable connection

pooling, because the ADO Managed Provider does so automatically. The SQL

Managed Provider relies on Windows 2000 Component Services to provide

connection pooling

</SNAP>



SQLConnection doesn't have any connection pooling, we have to do this with

Component services and use object pooling instead.

I hope MS change this in the final release, because many developers are

going to do this wrong, for example; they might use the SQLCOnnection

without using object pooling, because they think SQLCOnnection uses

connection pooling.



>We aren't passing arrays.  Here is a simple example.  Let's say we have a

>CShopper object.  A Shopper can have multiple addresses.  The Shopper

>object would have an ArrayList member called Addresses, which will be a

>collection of CAddress objects  There would be a method on the CShopper

>object called GetAddresses().  GetAddresses would make call to the

>database to get the addresses for this shopper and return them in a

>SQLDataReader.  It would then loop through the SQLDataReader creating new

>CAddress objects.  The CAddress objects would be created by passing the

>SQLDataReader into the constructor of CAddress, which would populate

>itself from the DataReader.

>fter all of this happens, our business layer accesses the Shopper's

>Addresses through the ArrayList member of Addresses.  The business layer

>is completely separated from knowing anything about a Database.  All it

>knows is that it called GetAddresses() and then is able to retrieve the

>addresses through the Shopper's Addresses collection.



Ok, it's very nice, but sometimes is much faster to pass a dataset or a

datareader instead of looping through the DataReader or the dataset and

creating a new class.



I have done my own classes instead of passing datasets or readers, but

sometimes when I will increase performance I pass a datareader or dataset

all the way to the presentation layer.



I've left out a ton of details, so don't start trying to tear this example

apart.



Best Regards,

Fredrik Normén

I did see your previous post about connection pooling.  We haven't 

looked into that yet, but will.  Thanks for the info.







-----Original Message-----

From: Fredrik Norm=E9n [mailto:fredrik.normen@e...]

Sent: Wednesday, November 29, 2000 9:44 AM

To: ASP+

Subject: [aspx] RE: SQLConnection speed vs. ADODB.Connection - Tier de

sign!





>Perhaps I should have stated much earlier on that I am not DIRECTLY

>passing around a SQLConnection or ADOConnection, but instead an object

>that encapsulates those and hides all of the details of the connection

>from my business layer.  Therefore, my business layer is never 

affected by

>any changes in my data-layer.



Have you read the mail regarding how to use connection pooling with

SQLConnection, if not here is a

 brief summary:



<SNAP>

To deploy high-performance applications, you need to use connection 

pooling.

When you use the ADO Managed Provider you do not need to enable 

connection

pooling, because the ADO Managed Provider does so automatically. The 

SQL

Managed Provider relies on Windows 2000 Component Services to provide

connection pooling

</SNAP>



SQLConnection doesn't have any connection pooling, we have to do this 

with

Component services and use object pooling instead.

I hope MS change this in the final release, because many developers are

going to do this wrong, for example; they might use the SQLCOnnection

without using object pooling, because they think SQLCOnnection uses

connection pooling.



>We aren't passing arrays.  Here is a simple example.  Let's say we 

have a

>CShopper object.  A Shopper can have multiple addresses.  The Shopper

>object would have an ArrayList member called Addresses, which will be 

a

>collection of CAddress objects  There would be a method on the 

CShopper

>object called GetAddresses().  GetAddresses would make call to the

>database to get the addresses for this shopper and return them in a

>SQLDataReader.  It would then loop through the SQLDataReader creating 

new

>CAddress objects.  The CAddress objects would be created by passing 

the

>SQLDataReader into the constructor of CAddress, which would populate

>itself from the DataReader.

>fter all of this happens, our business layer accesses the Shopper's

>Addresses through the ArrayList member of Addresses.  The business 

layer

>is completely separated from knowing anything about a Database.  All 

it

>knows is that it called GetAddresses() and then is able to retrieve 

the

>addresses through the Shopper's Addresses collection.



Ok, it's very nice, but sometimes is much faster to pass a dataset or a

datareader instead of looping through the DataReader or the dataset and

creating a new class.



I have done my own classes instead of passing datasets or readers, but

sometimes when I will increase performance I pass a datareader or 

dataset

all the way to the presentation layer.



I've left out a ton of details, so don't start trying to tear this 

example

apart.



Best Regards,

Fredrik Norm=E9n