Hello Everyone and thanks for your help in advance.  I am working through 

the IBuySpy.com example in the Microsoft Quick Start Tutorials and am 

trying to grasp some basic N-Tier concepts after much experience with 

classic ASP.  In this example and most others I have seen, it appears that 

to add, delete, or update a database, a class is developed to perform all 

data functions.  From there, in most cases, a stored procedure is executed 

to actually perform the database functions.  I understand the concepts of 

separating the tiers, but am confused with the methodology.  When using 

classic ASP, I typically created an "update page" which consisted of the 

connection to the database along with the pertinent code (no HTML) to 

perform the database manipulation, effectively separating the business 

tier from the presentation tier.  It seems that creating a new class to 

then execute a stored procedure is a lot of overhead, but it seems to be 

the standard these days for developing in .Net.  Could someone please 

explain to me why this method is better than the "update page" that I 

described.  Any feedback would be greatly appreciated.  Thanks.

Hi Hugh,

Here's my take on it.



Creating a separate class to act as the data tier does not create

overhead.  Creating a class, in general, does not create overhead.  For

one, it promotes code reuse.  Also, you can then compile the code into

an assembly to enhance performance even further.  Once the

class/assembly has been created you can then use this "Data Access

Layer" (DAL) from any application, anywhere in your enterprise.  A very

good thing.



I'm sure other people will have some more thoughts on this as well.



Doug





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

From: Hugh McLaughlin [mailto:hugh@k...] 

Sent: Thursday, January 10, 2002 5:03 AM

To: ASP+

Subject: [aspx] Basic N-Tier Concepts





Hello Everyone and thanks for your help in advance.  I am working

through 

the IBuySpy.com example in the Microsoft Quick Start Tutorials and am 

trying to grasp some basic N-Tier concepts after much experience with 

classic ASP.  In this example and most others I have seen, it appears

that 

to add, delete, or update a database, a class is developed to perform

all 

data functions.  From there, in most cases, a stored procedure is

executed 

to actually perform the database functions.  I understand the concepts

of 

separating the tiers, but am confused with the methodology.  When using 

classic ASP, I typically created an "update page" which consisted of the



connection to the database along with the pertinent code (no HTML) to 

perform the database manipulation, effectively separating the business 

tier from the presentation tier.  It seems that creating a new class to 

then execute a stored procedure is a lot of overhead, but it seems to be



the standard these days for developing in .Net.  Could someone please 

explain to me why this method is better than the "update page" that I 

described.  Any feedback would be greatly appreciated.  Thanks.

Let's start with the Legacy ASP Portion and COM...



In your example you suggested that you have an UpdatePage.asp that contains 

no presentation logic just business cases that are executed based (guessing) 

from data that was posted to it (POST/GET/or Mangling the URL with 

parameters).  Based from the Request Variables you probably have some case 

logic that determines what functions/sub procedures get executed.  Then you 

probably redirect the user to another page which may contain some Query 

String parameters as well.  I am also guessing that you are not using any 

COM components that encapsulate common functionality or business routines 

and in fact this is all annotated by the need of your scriptable functions.  

You also probably have either Application/Session/ and/or data types within 

the page scoped properly to contain the necessary Meta-Data if you will 

about connection information etc..



In this model there are many things to be concerned about(just to describe a 

few):

1) Performance - since all of your logic is scripting (minus ADODB 

components) every time a request is made your code has to be interpreted 

line by line and then executed (thus not being compiled code).  The more 

critical business logic that you have within ASP scripts the slower your 

response is going to be.



2) Process De-Coupling / Reusability - since all of your core business logic 

is with ASP scripts (through case logic - functions - sub procedures) you 

are crippled when you need to tier out a business process to another 

resource (or even to broadcast notifications using MSMQ , COM+ Events, or 

third-party apps such as Tibco [Middleware]) or when you want to reuse some 

functionality else where.  What happens when you need another ASP page to 

use just some of the already developed functionality in your Update page - 

do you now generate many include files (libraries) to share - do you copy 

and paste?  What happens if you have developed some real useful routines 

(such as data access) that need to be used in a Window's App - a Console App 

- or even a Service App - do you now have to develop a whole different set 

of components with the same functionality to accomplish the same task?



3) Usage - ASP was not meant to be used (in my mind) as a middle-layer 

technology.  ASP was to act (again in my mind) as the driver based upon web 

requests, navigating the traffic if you will to different stages of a 

pipelined process that do contain the business rules and functionality 

needed to accomplish a task.  ASP is also the glue between 2 important 

layers (at the simplest view) in this tiered model that you are talking 

about - The Presentation (which includes mark-up, styling, and light 

business logic e.g. client-side scripts) and The Application (called many 

other things e.g. Business Layer, Middle Layer)(which includes your core 

business objects) containing light business logic that is not to consume 

much of the interpretation time.



4) Fundamental OO Development - you won't see to much of this in this type 

of model nor being able to reap in the benefits of the many sought after 

concepts (Inheritance - Encapsulation - Polymorphism - Abstraction etc.).  

Being able to construct your organizations library's in such a manor and 

letting ASP to be just the "consumer" add's great value to your overall 

architecture.



Now onto to .NET - specifically ASP.NET...



1) Performance - since all ASP.NET pages are essentially complied (after the 

IL-to-Machine translation upon the first request and since your last 

deployed assembly build - not to mention JIT'ers and the GC) you won't be 

worrying to much of this (but still coding wise paying attention to it won't 

hurt either).



2) Process De-Coupling / Reusability - since (especially for C#) some of the 

.NET Compliant Languages are OO from the ground up - the construction of 

your overall architecture has to breath reusability (maintaining a good 

understanding of the concepts).  Object's Object's Object's (even down to 

your aspx page being derived from the System.Web.UI.Page class)...  So now 

the De-Coupling really become apparent - Presentation Classes - Data 

Processing Classes - which can not all be distributed to their related tier 

(Debugging becomes easier - yada yada ya).



3) Usage - I think this now is a architectural - requirement driven - and 

maybe a personal preference - since everything is complied it's up to you 

where to distribute the processes...  If you want to develop all of your 

classes with a code behind page.. .. Have at it.  If you want to separate 

the logic into separate assemblies.. .. Have at it.



4) Fundamental OO Development - Do I even need to go there?



Well back to work - I hope I was able to shed some light on the subject...



Al







>From: "Hugh McLaughlin" <hugh@k...>

>Reply-To: "ASP+" <aspx@p...>

>To: "ASP+" <aspx@p...>

>Subject: [aspx] Basic N-Tier Concepts

>Date: Thu, 10 Jan 2002 05:03:22

>

>Hello Everyone and thanks for your help in advance.  I am working through

>the IBuySpy.com example in the Microsoft Quick Start Tutorials and am

>trying to grasp some basic N-Tier concepts after much experience with

>classic ASP.  In this example and most others I have seen, it appears that

>to add, delete, or update a database, a class is developed to perform all

>data functions.  From there, in most cases, a stored procedure is executed

>to actually perform the database functions.  I understand the concepts of

>separating the tiers, but am confused with the methodology.  When using

>classic ASP, I typically created an "update page" which consisted of the

>connection to the database along with the pertinent code (no HTML) to

>perform the database manipulation, effectively separating the business

>tier from the presentation tier.  It seems that creating a new class to

>then execute a stored procedure is a lot of overhead, but it seems to be

>the standard these days for developing in .Net.  Could someone please

>explain to me why this method is better than the "update page" that I

>described.  Any feedback would be greatly appreciated.  Thanks.












_________________________________________________________________

Join the world?s largest e-mail service with MSN Hotmail. 

http://www.hotmail.com

> Let's start with the Legacy ASP Portion and COM...

> 

> In your example you suggested that you have an UpdatePage.asp that 

contains 

> no presentation logic just business cases that are executed based 

(guessing) 

> from data that was posted to it (POST/GET/or Mangling the URL with 

> parameters).  Based from the Request Variables you probably have some 

case 

> logic that determines what functions/sub procedures get executed.  Then 

you 

> probably redirect the user to another page which may contain some Query 

> String parameters as well.  I am also guessing that you are not using 

any 

> COM components that encapsulate common functionality or business 

routines 

> and in fact this is all annotated by the need of your scriptable 

functions.  

> You also probably have either Application/Session/ and/or data types 

within 

> the page scoped properly to contain the necessary Meta-Data if you will 

> about connection information etc..

> 

> In this model there are many things to be concerned about(just to 

describe a 

> few):

> 1) Performance - since all of your logic is scripting (minus ADODB 

> components) every time a request is made your code has to be 

interpreted 

> line by line and then executed (thus not being compiled code).  The 

more 

> critical business logic that you have within ASP scripts the slower 

your 

> response is going to be.

> 

> 2) Process De-Coupling / Reusability - since all of your core business 

logic 

> is with ASP scripts (through case logic - functions - sub procedures) 

you 

> are crippled when you need to tier out a business process to another 

> resource (or even to broadcast notifications using MSMQ , COM+ Events, 

or 

> third-party apps such as Tibco [Middleware]) or when you want to reuse 

some 

> functionality else where.  What happens when you need another ASP page 

to 

> use just some of the already developed functionality in your Update 

page - 

> do you now generate many include files (libraries) to share - do you 

copy 

> and paste?  What happens if you have developed some real useful 

routines 

> (such as data access) that need to be used in a Window's App - a 

Console App 

> - or even a Service App - do you now have to develop a whole different 

set 

> of components with the same functionality to accomplish the same task?

> 

> 3) Usage - ASP was not meant to be used (in my mind) as a middle-layer 

> technology.  ASP was to act (again in my mind) as the driver based upon 

web 

> requests, navigating the traffic if you will to different stages of a 

> pipelined process that do contain the business rules and functionality 

> needed to accomplish a task.  ASP is also the glue between 2 important 

> layers (at the simplest view) in this tiered model that you are talking 

> about - The Presentation (which includes mark-up, styling, and light 

> business logic e.g. client-side scripts) and The Application (called 

many 

> other things e.g. Business Layer, Middle Layer)(which includes your 

core 

> business objects) containing light business logic that is not to 

consume 

> much of the interpretation time.

> 

> 4) Fundamental OO Development - you won't see to much of this in this 

type 

> of model nor being able to reap in the benefits of the many sought 

after 

> concepts (Inheritance - Encapsulation - Polymorphism - Abstraction 

etc.).  

> Being able to construct your organizations library's in such a manor 

and 

> letting ASP to be just the "consumer" add's great value to your overall 

> architecture.

> 

> Now onto to .NET - specifically ASP.NET...

> 

> 1) Performance - since all ASP.NET pages are essentially complied 

(after the 

> IL-to-Machine translation upon the first request and since your last 

> deployed assembly build - not to mention JIT'ers and the GC) you won't 

be 

> worrying to much of this (but still coding wise paying attention to it 

won't 

> hurt either).

> 

> 2) Process De-Coupling / Reusability - since (especially for C#) some 

of the 

> .NET Compliant Languages are OO from the ground up - the construction 

of 

> your overall architecture has to breath reusability (maintaining a good 

> understanding of the concepts).  Object's Object's Object's (even down 

to 

> your aspx page being derived from the System.Web.UI.Page class)...  So 

now 

> the De-Coupling really become apparent - Presentation Classes - Data 

> Processing Classes - which can not all be distributed to their related 

tier 

> (Debugging becomes easier - yada yada ya).

> 

> 3) Usage - I think this now is a architectural - requirement driven - 

and 

> maybe a personal preference - since everything is complied it's up to 

you 

> where to distribute the processes...  If you want to develop all of 

your 

> classes with a code behind page.. .. Have at it.  If you want to 

separate 

> the logic into separate assemblies.. .. Have at it.

> 

> 4) Fundamental OO Development - Do I even need to go there?

> 

> Well back to work - I hope I was able to shed some light on the 

subject...

> 

> Al

> 

> 

> 

> >From: "Hugh McLaughlin" <hugh@k...>

> >Reply-To: "ASP+" <aspx@p...>

> >To: "ASP+" <aspx@p...>

> >Subject: [aspx] Basic N-Tier Concepts

> >Date: Thu, 10 Jan 2002 05:03:22

> >

> >Hello Everyone and thanks for your help in advance.  I am working 

through

> >the IBuySpy.com example in the Microsoft Quick Start Tutorials and am

> >trying to grasp some basic N-Tier concepts after much experience with

> >classic ASP.  In this example and most others I have seen, it appears 

that

> >to add, delete, or update a database, a class is developed to perform 

all

> >data functions.  From there, in most cases, a stored procedure is 

executed

> >to actually perform the database functions.  I understand the concepts 

of

> >separating the tiers, but am confused with the methodology.  When using

> >classic ASP, I typically created an "update page" which consisted of 

the

> >connection to the database along with the pertinent code (no HTML) to

> >perform the database manipulation, effectively separating the business

> >tier from the presentation tier.  It seems that creating a new class to

> >then execute a stored procedure is a lot of overhead, but it seems to 

be

> >the standard these days for developing in .Net.  Could someone please

> >explain to me why this method is better than the "update page" that I

> >described.  Any feedback would be greatly appreciated.  Thanks.




> 

> 

> 

> 

> _________________________________________________________________

> Join the world?s largest e-mail service with MSN Hotmail. 

> http://www.hotmail.com

> 

First of all, thanks for both of your responses.  As with most responses, 

they create more questions.  Given my "update page" example, if I simply 

made it an ASPX page, it would then compile, thus improving performance.  

As far a reusability, isn't any database related code going to be bounded 

by the input to the code and the tables(s) they are working with.  I 

guess I am just not understanding all of the benefits to the new methods.

Yes and no - it really depends on how well your good at architecture 

analysis - For simplicity:



You can construct your core components in such a way that they understand 

what needs to happen at the data abstraction layer and thus every 

application consuming them won't need to understand the "How" but are more 

concerned with some feedback that doesn't necessary have to be a native 

record set but can be serialized into other user-defined data types as well 

as just an overall wrappered data-access layer even within this that 

contains well written access methods that are solid which don't want to be 

re-written.  Example:



Say I have a web-based system that needs to display an Invoice for all 

client's that have purchased some goods - but promoting the paperless theory 

we have to email them a notice that they have another Invoice available to 

them to be paid online.  When the customer logs into there account - clicks 

account management - Unpaid Invoices - they get displayed any number of 

invoices that are to be paid.  So with this said now take a look at how this 

could be constructed...



Step One (The Invoice).

Since we know that we have to display an invoice if we look at this in terms 

of OO analysis we see the need of a class called "Invoice".  But since there 

can be many different types of Invoices you will probably want to construct 

some type of abstract definition of this that has the core elements needed 

by any Invoice Types as well as some Must-Have functionality to be deployed. 

  Then from this abstract definition we could create a derived class by the 

name of "UnPaidProductInvoice" and add it's specific attributes additional 

needed as well as the enforced functionality needed by "Invoice".



Step Two (Serialization)

Now that we have a class that can hold an Unpaid Invoice the "real" invoice 

are within our data store e.g. Sql Server...  Since applications don't care 

on how we get the Unpaid Invoice attributes and only care about having an 

object reference to an Invoice we hide the data abstraction layer and thus 

also allowing us to change it's functionality in case we want to change how 

an Unpaid Invoice is getting stored or its location...  So now we can 

instantiate an "UnPaidProductInvoice" object set maybe a property called 

"UserName"

and then call a method called "GetCurrentInvoice()" and voila any 

application using this object only cares about what the current invoice is 

such as calling another property "Products" which would return a collection 

of Products that haven't been paid for display etc...  Actually this by 

itself is a not so good design as you would want an 

"UnPaidProductInvoiceCollection" class that contains a list of 

"UnPaidProductInvoice"'s, I was just trying to keep it simple.



So in this example "GetCurrentInvoice()" will actually (with probably the 

help of some local methods) do the Data Marshalling in where a DataReader 

contains the serialized invoice data and we will de-serialization by setting 

the Invoices fields that correspond to the recordset's Invoice row on that 

Invoice table.  Now any application can use the "UnPaidProductInvoice" 

without having to understand the guts and based upon the contracted 

interface we can at anytime change the underlying functionality without 

breaking any application that has consumed it.



Taking this a step further the "GetCurrentInvoice()" methods and its 

supporting methods can be using another data-access class designed to 

wrapper the most common functionality that your applications will use when 

connecting with an OleDb or SqlClient provider.  This way all of the mundane 

steps of setting up the connection, executing a stored proc, etc..  doesn't 

have to be repeated when 7 times out of 10 you just want a DataSet to work 

with - so you could design this data-access layer to accept a sql string and 

pass you back a DataSet all in one step e.g. 

"ExecuteStoredProc(mySqlString)" in where the returning data type is a 

DataSet....



Al

>From: "Hugh McLaughlin" <hugh@k...>

>Reply-To: "ASP+" <aspx@p...>

>To: "ASP+" <aspx@p...>

>Subject: [aspx] Re: Basic N-Tier Concepts

>Date: Thu, 10 Jan 2002 16:19:25

>

> > Let's start with the Legacy ASP Portion and COM...

> >

> > In your example you suggested that you have an UpdatePage.asp that

>contains

> > no presentation logic just business cases that are executed based

>(guessing)

> > from data that was posted to it (POST/GET/or Mangling the URL with

> > parameters).  Based from the Request Variables you probably have some

>case

> > logic that determines what functions/sub procedures get executed.  Then

>you

> > probably redirect the user to another page which may contain some Query

> > String parameters as well.  I am also guessing that you are not using

>any

> > COM components that encapsulate common functionality or business

>routines

> > and in fact this is all annotated by the need of your scriptable

>functions.

> > You also probably have either Application/Session/ and/or data types

>within

> > the page scoped properly to contain the necessary Meta-Data if you will

> > about connection information etc..

> >

> > In this model there are many things to be concerned about(just to

>describe a

> > few):

> > 1) Performance - since all of your logic is scripting (minus ADODB

> > components) every time a request is made your code has to be

>interpreted

> > line by line and then executed (thus not being compiled code).  The

>more

> > critical business logic that you have within ASP scripts the slower

>your

> > response is going to be.

> >

> > 2) Process De-Coupling / Reusability - since all of your core business

>logic

> > is with ASP scripts (through case logic - functions - sub procedures)

>you

> > are crippled when you need to tier out a business process to another

> > resource (or even to broadcast notifications using MSMQ , COM+ Events,

>or

> > third-party apps such as Tibco [Middleware]) or when you want to reuse

>some

> > functionality else where.  What happens when you need another ASP page

>to

> > use just some of the already developed functionality in your Update

>page -

> > do you now generate many include files (libraries) to share - do you

>copy

> > and paste?  What happens if you have developed some real useful

>routines

> > (such as data access) that need to be used in a Window's App - a

>Console App

> > - or even a Service App - do you now have to develop a whole different

>set

> > of components with the same functionality to accomplish the same task?

> >

> > 3) Usage - ASP was not meant to be used (in my mind) as a middle-layer

> > technology.  ASP was to act (again in my mind) as the driver based upon

>web

> > requests, navigating the traffic if you will to different stages of a

> > pipelined process that do contain the business rules and functionality

> > needed to accomplish a task.  ASP is also the glue between 2 important

> > layers (at the simplest view) in this tiered model that you are talking

> > about - The Presentation (which includes mark-up, styling, and light

> > business logic e.g. client-side scripts) and The Application (called

>many

> > other things e.g. Business Layer, Middle Layer)(which includes your

>core

> > business objects) containing light business logic that is not to

>consume

> > much of the interpretation time.

> >

> > 4) Fundamental OO Development - you won't see to much of this in this

>type

> > of model nor being able to reap in the benefits of the many sought

>after

> > concepts (Inheritance - Encapsulation - Polymorphism - Abstraction

>etc.).

> > Being able to construct your organizations library's in such a manor

>and

> > letting ASP to be just the "consumer" add's great value to your overall

> > architecture.

> >

> > Now onto to .NET - specifically ASP.NET...

> >

> > 1) Performance - since all ASP.NET pages are essentially complied

>(after the

> > IL-to-Machine translation upon the first request and since your last

> > deployed assembly build - not to mention JIT'ers and the GC) you won't

>be

> > worrying to much of this (but still coding wise paying attention to it

>won't

> > hurt either).

> >

> > 2) Process De-Coupling / Reusability - since (especially for C#) some

>of the

> > .NET Compliant Languages are OO from the ground up - the construction

>of

> > your overall architecture has to breath reusability (maintaining a good

> > understanding of the concepts).  Object's Object's Object's (even down

>to

> > your aspx page being derived from the System.Web.UI.Page class)...  So

>now

> > the De-Coupling really become apparent - Presentation Classes - Data

> > Processing Classes - which can not all be distributed to their related

>tier

> > (Debugging becomes easier - yada yada ya).

> >

> > 3) Usage - I think this now is a architectural - requirement driven -

>and

> > maybe a personal preference - since everything is complied it's up to

>you

> > where to distribute the processes...  If you want to develop all of

>your

> > classes with a code behind page.. .. Have at it.  If you want to

>separate

> > the logic into separate assemblies.. .. Have at it.

> >

> > 4) Fundamental OO Development - Do I even need to go there?

> >

> > Well back to work - I hope I was able to shed some light on the

>subject...

> >

> > Al

> >

> >

> >

> > >From: "Hugh McLaughlin" <hugh@k...>

> > >Reply-To: "ASP+" <aspx@p...>

> > >To: "ASP+" <aspx@p...>

> > >Subject: [aspx] Basic N-Tier Concepts

> > >Date: Thu, 10 Jan 2002 05:03:22

> > >

> > >Hello Everyone and thanks for your help in advance.  I am working

>through

> > >the IBuySpy.com example in the Microsoft Quick Start Tutorials and am

> > >trying to grasp some basic N-Tier concepts after much experience with

> > >classic ASP.  In this example and most others I have seen, it appears

>that

> > >to add, delete, or update a database, a class is developed to perform

>all

> > >data functions.  From there, in most cases, a stored procedure is

>executed

> > >to actually perform the database functions.  I understand the concepts

>of

> > >separating the tiers, but am confused with the methodology.  When using

> > >classic ASP, I typically created an "update page" which consisted of

>the

> > >connection to the database along with the pertinent code (no HTML) to

> > >perform the database manipulation, effectively separating the business

> > >tier from the presentation tier.  It seems that creating a new class to

> > >then execute a stored procedure is a lot of overhead, but it seems to

>be

> > >the standard these days for developing in .Net.  Could someone please

> > >explain to me why this method is better than the "update page" that I

> > >described.  Any feedback would be greatly appreciated.  Thanks.




> >

> >

> >

> >

> > _________________________________________________________________

> > Join the world?s largest e-mail service with MSN Hotmail.

> > http://www.hotmail.com

> >

>First of all, thanks for both of your responses.  As with most responses,

>they create more questions.  Given my "update page" example, if I simply

>made it an ASPX page, it would then compile, thus improving performance.

>As far a reusability, isn't any database related code going to be bounded

>by the input to the code and the tables(s) they are working with.  I

>guess I am just not understanding all of the benefits to the new methods.












_________________________________________________________________

Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.