By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,117 Members | 2,178 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,117 IT Pros & Developers. It's quick & easy.

n-Tier development

P: n/a
Ok, I've never done n-Tier development and I'm getting confused...

Assuming I have a business layer and a data access layer that may be running
on different machines, how does my business layer know where my data access
layer is running? What is it I have to do in the business layer that
"creates" the data access layer on the other server?

Second, what do I pass between my business layer and my data access layer?
Should I be returning a dataset from the data access layer to the business
layer and letting the business layer convert it in to business objects, or
should my data access layer return business objects?

For example, assume my business layer deals with "Client" objects. Should my
business layer ask my data access layer to return it a "client" object,
leaving the data access layer to determine what that involves, or does my
business layer ask the data access layer for some information from tables
and then the business layer builds the client object from the returned
dataset(s). If so, who builds the SQL, which I thought would be a DAL
function.

As you can probably tell, I could do with a simple (but practical) tutorial
on n-Tier development... anyone know of a good one as it relates to DESKTOP
based applications. Unfortunately, this app I'm working on is not a web
based app.

Thanks
Steve
Jan 30 '06 #1
Share this Question
Share on Google+
23 Replies


P: n/a
i have gone through ur query, if u want the data access on different machine
then u have to refer(somehow) the data access layer DLL in the business layer.
u can return both the dataset and as well as object, it depends on u.
--
If u have the hammer every problem will look like a nail.
"Steve Barnett" wrote:
Ok, I've never done n-Tier development and I'm getting confused...

Assuming I have a business layer and a data access layer that may be running
on different machines, how does my business layer know where my data access
layer is running? What is it I have to do in the business layer that
"creates" the data access layer on the other server?

Second, what do I pass between my business layer and my data access layer?
Should I be returning a dataset from the data access layer to the business
layer and letting the business layer convert it in to business objects, or
should my data access layer return business objects?

For example, assume my business layer deals with "Client" objects. Should my
business layer ask my data access layer to return it a "client" object,
leaving the data access layer to determine what that involves, or does my
business layer ask the data access layer for some information from tables
and then the business layer builds the client object from the returned
dataset(s). If so, who builds the SQL, which I thought would be a DAL
function.

As you can probably tell, I could do with a simple (but practical) tutorial
on n-Tier development... anyone know of a good one as it relates to DESKTOP
based applications. Unfortunately, this app I'm working on is not a web
based app.

Thanks
Steve

Jan 30 '06 #2

P: n/a
Steve Barnett wrote:
Ok, I've never done n-Tier development and I'm getting confused...

Assuming I have a business layer and a data access layer that may be running
on different machines, how does my business layer know where my data access
layer is running? What is it I have to do in the business layer that
"creates" the data access layer on the other server?

Second, what do I pass between my business layer and my data access layer?
Should I be returning a dataset from the data access layer to the business
layer and letting the business layer convert it in to business objects, or
should my data access layer return business objects?

For example, assume my business layer deals with "Client" objects. Should my
business layer ask my data access layer to return it a "client" object,
leaving the data access layer to determine what that involves, or does my
business layer ask the data access layer for some information from tables
and then the business layer builds the client object from the returned
dataset(s). If so, who builds the SQL, which I thought would be a DAL
function.

As you can probably tell, I could do with a simple (but practical) tutorial
on n-Tier development... anyone know of a good one as it relates to DESKTOP
based applications. Unfortunately, this app I'm working on is not a web
based app.

Thanks
Steve


I don't see why you'd want to have DAL and BLL on 2 separate computers.
You'd have to use something like a web service or remoting between the
two... That would very much suck IMHO, and do nothing good but add more
latency (ok, that ain't good either ;)) If one machine doesn't have
enough power, you can load balance between 2+ machines that has both the
DAL+BLL on them (all the middleware).

Between DAL & BLL, you could pass several things... Some people pass
DataSets, others pass DataReaders, or you can use some translation
layer/class between them to translate it to business objects at that
point... It seems to be a matter of preferences really.

As for building SQL, that would be the DAL's function, but it shouldn't
have to build very much... Most queries should be hardcoded really...
The only queries I usually generate are the complex ones - those for
complex searches or custom paging and such. Most queries (plain CRUD
operations on the DB) are static (hand coded or generated by some
automation tool).

Whether it's a web app or a desktop app, the n-tier principles are
mainly the same, you just tend to use/connect to the middleware
differently. If you seach on codeproject.com I'm sure you'll find
several n-tier dev articles.
Jan 30 '06 #3

P: n/a
CMM
Don't listen to that other poster. I'll give you a really simple example on
why programmers in the last five years have lost their minds.... and have
forgotten all the lessons a lot of us learned in the 90's.

What developers call "tiers" nowadays, I call simple "encapsulation".... NOT
TIERS. Somewhere a mass hypnosis has taken root across the development world
concerning this.

Here's an example:

1) Supposse your DAL is on the client machine like the other user recommends
(making it a 2-tiered App). You have a dataset where you've changed 10 rows.
Calling Update on a DataAdapter with this dataset will result in your update
stored proc (or update sql) being called 10 times! That's 10 network round
trips.... across a busy 100-megabit network!
2) Even more likely you've changed one record in one table and 1 record in 3
other related child tables (Employe--EmployeAddresses--etc.). That's 4 round
trips. Your app is now a VERY CHATTY application. A network's nightmare.
3) In a true N-Tier structure (a 3-tiered App where the DAL is an another
machine) there's only ONE round trip with your DAL.
4) Now, your DAL and DB servers are connected via 1-gigabit(!)
connection....(this is common)...and connected to each other via a dedicated
switch (so their conversations don't swamp the network the way your old
2-tiered rinky dink app did).
5) ...Or even better are on the SAME server. The round trips don't matter AT
ALL.
6) Now imagine that your client app needs to run on a simple VPN with an
office overseas. Your old 2-tiered rinky dink app is TOTALLY UNUSABLE and
not much better than your employees using an Access MDB on shared workgroup
server a la Windows 3.1.

Developers think that because they put their data access in a separate files
that they're code warriors and doing something special. In fact, they're not
doing much at all except achieving nice encapsulation (always a good
practice!). They're creating simple 2-tiered apps that people were coding in
1996 and suffering later for it.

P.S.
ADO.NET 2.0 with SQL Server 2005 introduces "batch updating" which addresses
some of these concerns. But there are HUGE caveats with batch updating that
render it almost useless (like returning Id's from INSERTS, etc) and almost
always require a "rescan" of the affected tables... rendering moot any
performance gains gotten by using batch updating. Again, TRUE N-TIER
development is the answer here.

P.P.S.
You use remoted objects quite easily.... (and building your own barebones
remoting host is super-duper easy... but, if you need object pooling and
stuff like that you'll need to run them in IIS or Windows Server Component
Services).

Dim o As IContactsService =
Activator.GetObject(GetType(IContactsService), serverUri)

where IContactsService is an Interface in a lightweight DLL that exists on
the server and client. Optionally you can put the server components directly
on the client.

Check out these links
-http://www.thinktecture.com/Resources/RemotingFAQ/default.html
-http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/introremoting.asp

"Steve Barnett" <no****@nodomain.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
Ok, I've never done n-Tier development and I'm getting confused...

Assuming I have a business layer and a data access layer that may be
running on different machines, how does my business layer know where my
data access layer is running? What is it I have to do in the business
layer that "creates" the data access layer on the other server?

Second, what do I pass between my business layer and my data access layer?
Should I be returning a dataset from the data access layer to the business
layer and letting the business layer convert it in to business objects, or
should my data access layer return business objects?

For example, assume my business layer deals with "Client" objects. Should
my business layer ask my data access layer to return it a "client" object,
leaving the data access layer to determine what that involves, or does my
business layer ask the data access layer for some information from tables
and then the business layer builds the client object from the returned
dataset(s). If so, who builds the SQL, which I thought would be a DAL
function.

As you can probably tell, I could do with a simple (but practical)
tutorial on n-Tier development... anyone know of a good one as it relates
to DESKTOP based applications. Unfortunately, this app I'm working on is
not a web based app.

Thanks
Steve

Jan 30 '06 #4

P: n/a
CMM
I disagree with almost everything you state.
See below for my inline comments:

"john smith" <jo**@smith.com> wrote in message
news:Ob**************@TK2MSFTNGP10.phx.gbl...
I don't see why you'd want to have DAL and BLL on 2 separate computers.
You'd have to use something like a web service or remoting between the
two... That would very much suck IMHO, and do nothing good but add more
latency (ok, that ain't good either ;)) If one machine doesn't have enough
power, you can load balance between 2+ machines that has both the DAL+BLL
on them (all the middleware).
See my other post. It's all about round trips... and not even about
load-balancing and "high-end stuff." Even a minor app with about 20 users
benefits from a true 3-Tiered design (3-Tiered meaning the DAL is another
machine).

See my reply to the original poster for more.

Between DAL & BLL, you could pass several things... Some people pass
DataSets, others pass DataReaders,
Passing DataReaders is horrible (pre .NET 2.0, anyway). Do I need to explain
why? Do people actually still do this?
or you can use some translation layer/class between them to translate it to
business objects at that point... It seems to be a matter of preferences
really.
Yes. Datasets can behave like busines entities if you wanted them to.
Spending time with ORM is such a waste of time when Typed Datasets do
anything and everything you could hope to accomplish. I like the "Document"
paradigm... where service classes act ON the dataset (validators, data
access, etc) and the dataset is basically dumb. It's clean and modular. I
can change a "validation service" without ever touching the dataset class or
the client application.

As for building SQL, that would be the DAL's function, but it shouldn't
have to build very much... Most queries should be hardcoded really..
Why?
Will someone please explain (and defend!) this fairly common supposition?

.. The only queries I usually generate are the complex ones - those for
complex searches or custom paging and such.
Seems to me that these exact type of queries are the ONLY queries that
actually benefit from stored procedures / functions (because of compliation
and query plans and optimization and stuff like that).

But this....
Most queries (plain CRUD operations on the DB) are static (hand coded or
generated by some automation tool).
is retarded. Wrapping up *every* little INSERT/UPDATE simple SELECT in a
stored proc is retarded. It's not that its "wrong"... I'm not against it and
in fact I even like it (it seems untuitively "orderly")....it's just that 1)
it doesn't accomplish much and 2) it's totally expensive and unmanageable in
the long run unless you have a whole dedicated DBA team. It's not worth the
effort for the little payoff that it provides.

Whether it's a web app or a desktop app, the n-tier principles are mainly
the same, you just tend to use/connect to the middleware differently.
Not true. In n-Tier the middleware is stateless. This is a big design
difference. However, invocation is not all that different and it sounds
scarier than it really is (ooohh remoting host exe-- what is that? I'm
scared.).
If you seach on codeproject.com I'm sure you'll find several n-tier dev
articles.


Jan 30 '06 #5

P: n/a
CMM,

Altough we completely agree about what you write about encapulation and
mixing this up with Tiers. Is in my opinion your calculation not correcte
and the way you tell that a real physical Tier needed as well not.

To communicate with the middle tier on that seperate computer, you have to
communicate as well with that middle tier. However now it has to do it
twice, one time on your so called 1Gb line and the same as before on your
100Mb line in your sample. The clientcomputer (which is not a terminal) need
the same amount of information and has the same amount of updates.

Therefore there is only an extra piece of datacommunication introduced. The
transport of data on your 1Gb line.

For me the multitier is right in the Terminal application situation (not
windowsclient emulating). In the windowsform situation I see no advantages,
while this Terminal situated 3 tier is already done by a classic ASP or
ASPNET application where the browser functions in a way as a Terminal and
the application as a middle tier.

By the way probably before 1996 multi tier were more common because it is a
very good practise on a real Terminal based computer as Unix and other
Mainframes.

Just my thought,

Cor

"CMM" <cm*@nospam.com> schreef in bericht
news:ej**************@TK2MSFTNGP09.phx.gbl...
Don't listen to that other poster. I'll give you a really simple example
on why programmers in the last five years have lost their minds.... and
have forgotten all the lessons a lot of us learned in the 90's.

What developers call "tiers" nowadays, I call simple "encapsulation"....
NOT TIERS. Somewhere a mass hypnosis has taken root across the development
world concerning this.

Here's an example:

1) Supposse your DAL is on the client machine like the other user
recommends (making it a 2-tiered App). You have a dataset where you've
changed 10 rows. Calling Update on a DataAdapter with this dataset will
result in your update stored proc (or update sql) being called 10 times!
That's 10 network round trips.... across a busy 100-megabit network!
2) Even more likely you've changed one record in one table and 1 record in
3 other related child tables (Employe--EmployeAddresses--etc.). That's 4
round trips. Your app is now a VERY CHATTY application. A network's
nightmare.
3) In a true N-Tier structure (a 3-tiered App where the DAL is an another
machine) there's only ONE round trip with your DAL.
4) Now, your DAL and DB servers are connected via 1-gigabit(!)
connection....(this is common)...and connected to each other via a
dedicated switch (so their conversations don't swamp the network the way
your old 2-tiered rinky dink app did).
5) ...Or even better are on the SAME server. The round trips don't matter
AT ALL.
6) Now imagine that your client app needs to run on a simple VPN with an
office overseas. Your old 2-tiered rinky dink app is TOTALLY UNUSABLE and
not much better than your employees using an Access MDB on shared
workgroup server a la Windows 3.1.

Developers think that because they put their data access in a separate
files that they're code warriors and doing something special. In fact,
they're not doing much at all except achieving nice encapsulation (always
a good practice!). They're creating simple 2-tiered apps that people were
coding in 1996 and suffering later for it.

P.S.
ADO.NET 2.0 with SQL Server 2005 introduces "batch updating" which
addresses some of these concerns. But there are HUGE caveats with batch
updating that render it almost useless (like returning Id's from INSERTS,
etc) and almost always require a "rescan" of the affected tables...
rendering moot any performance gains gotten by using batch updating.
Again, TRUE N-TIER development is the answer here.

P.P.S.
You use remoted objects quite easily.... (and building your own barebones
remoting host is super-duper easy... but, if you need object pooling and
stuff like that you'll need to run them in IIS or Windows Server Component
Services).

Dim o As IContactsService =
Activator.GetObject(GetType(IContactsService), serverUri)

where IContactsService is an Interface in a lightweight DLL that exists on
the server and client. Optionally you can put the server components
directly on the client.

Check out these links
-http://www.thinktecture.com/Resources/RemotingFAQ/default.html
-http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/introremoting.asp

"Steve Barnett" <no****@nodomain.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
Ok, I've never done n-Tier development and I'm getting confused...

Assuming I have a business layer and a data access layer that may be
running on different machines, how does my business layer know where my
data access layer is running? What is it I have to do in the business
layer that "creates" the data access layer on the other server?

Second, what do I pass between my business layer and my data access
layer? Should I be returning a dataset from the data access layer to the
business layer and letting the business layer convert it in to business
objects, or should my data access layer return business objects?

For example, assume my business layer deals with "Client" objects. Should
my business layer ask my data access layer to return it a "client"
object, leaving the data access layer to determine what that involves, or
does my business layer ask the data access layer for some information
from tables and then the business layer builds the client object from the
returned dataset(s). If so, who builds the SQL, which I thought would be
a DAL function.

As you can probably tell, I could do with a simple (but practical)
tutorial on n-Tier development... anyone know of a good one as it relates
to DESKTOP based applications. Unfortunately, this app I'm working on is
not a web based app.

Thanks
Steve


Jan 30 '06 #6

P: n/a
CMM
I know what you're saying... but I think you're missing my point...

Talking about desktop WindowsForms apps here...

You're off in your description of the "double-communication" (though I see
what you mean). You have to think about how Ethernet works. In a 2-tiered
app four updates sent to the database BROADCASTS eight (!) trips across YOUR
ENTIRE LAN. This affects EVERY SINGLE user's workstation in your LAN. Isn't
it better for you to just send *one* message and let DAL and DB talk to each
other isolated and do their little 4-command conversation?

You have to take a step back and think about this... The client workstation
and the LAN-in-general are used for other things not just *your app.*
There's web browsing going on, e-mailing being done, and Joe in the next
cubicle downloading the VS2005 4 GB ISO file from msdn.microsoft.com. I'd
rather a bunch of INSERT/UPDATE statements happen between the DAL Server and
the DB Server (with the DAL on the same machine as the DB or through a
dedicated switch- so the LAN at large is not affected).

I think it is. In almost every single situation.

[Workstation]
|
<dataset with changes>
|
[App Server (DAL/Validation)]
| | | |
<update statements>
| | | |
[Database Server]
P.S. I don't advocate 3-tiered remoting between ASP.NET and the DB. In this
case the Web Server and the DB Server should be hooked (and switched)
together and communication between them is isolated and super-fast (if
they're not on the same machine to begin with which a lot people do too!).
The LAN caveats that I describe do not apply in this set-up as they're
already Server-to-Server.

"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:%2***************@TK2MSFTNGP12.phx.gbl...
CMM,

Altough we completely agree about what you write about encapulation and
mixing this up with Tiers. Is in my opinion your calculation not correcte
and the way you tell that a real physical Tier needed as well not.

To communicate with the middle tier on that seperate computer, you have to
communicate as well with that middle tier. However now it has to do it
twice, one time on your so called 1Gb line and the same as before on your
100Mb line in your sample. The clientcomputer (which is not a terminal)
need the same amount of information and has the same amount of updates.

Therefore there is only an extra piece of datacommunication introduced.
The transport of data on your 1Gb line.

For me the multitier is right in the Terminal application situation (not
windowsclient emulating). In the windowsform situation I see no
advantages, while this Terminal situated 3 tier is already done by a
classic ASP or ASPNET application where the browser functions in a way as
a Terminal and the application as a middle tier.

By the way probably before 1996 multi tier were more common because it is
a very good practise on a real Terminal based computer as Unix and other
Mainframes.

Just my thought,

Cor

"CMM" <cm*@nospam.com> schreef in bericht
news:ej**************@TK2MSFTNGP09.phx.gbl...
Don't listen to that other poster. I'll give you a really simple example
on why programmers in the last five years have lost their minds.... and
have forgotten all the lessons a lot of us learned in the 90's.

What developers call "tiers" nowadays, I call simple "encapsulation"....
NOT TIERS. Somewhere a mass hypnosis has taken root across the
development world concerning this.

Here's an example:

1) Supposse your DAL is on the client machine like the other user
recommends (making it a 2-tiered App). You have a dataset where you've
changed 10 rows. Calling Update on a DataAdapter with this dataset will
result in your update stored proc (or update sql) being called 10 times!
That's 10 network round trips.... across a busy 100-megabit network!
2) Even more likely you've changed one record in one table and 1 record
in 3 other related child tables (Employe--EmployeAddresses--etc.). That's
4 round trips. Your app is now a VERY CHATTY application. A network's
nightmare.
3) In a true N-Tier structure (a 3-tiered App where the DAL is an another
machine) there's only ONE round trip with your DAL.
4) Now, your DAL and DB servers are connected via 1-gigabit(!)
connection....(this is common)...and connected to each other via a
dedicated switch (so their conversations don't swamp the network the way
your old 2-tiered rinky dink app did).
5) ...Or even better are on the SAME server. The round trips don't matter
AT ALL.
6) Now imagine that your client app needs to run on a simple VPN with an
office overseas. Your old 2-tiered rinky dink app is TOTALLY UNUSABLE and
not much better than your employees using an Access MDB on shared
workgroup server a la Windows 3.1.

Developers think that because they put their data access in a separate
files that they're code warriors and doing something special. In fact,
they're not doing much at all except achieving nice encapsulation (always
a good practice!). They're creating simple 2-tiered apps that people were
coding in 1996 and suffering later for it.

P.S.
ADO.NET 2.0 with SQL Server 2005 introduces "batch updating" which
addresses some of these concerns. But there are HUGE caveats with batch
updating that render it almost useless (like returning Id's from INSERTS,
etc) and almost always require a "rescan" of the affected tables...
rendering moot any performance gains gotten by using batch updating.
Again, TRUE N-TIER development is the answer here.

P.P.S.
You use remoted objects quite easily.... (and building your own barebones
remoting host is super-duper easy... but, if you need object pooling and
stuff like that you'll need to run them in IIS or Windows Server
Component Services).

Dim o As IContactsService =
Activator.GetObject(GetType(IContactsService), serverUri)

where IContactsService is an Interface in a lightweight DLL that exists
on the server and client. Optionally you can put the server components
directly on the client.

Check out these links
-http://www.thinktecture.com/Resources/RemotingFAQ/default.html
-http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/introremoting.asp

"Steve Barnett" <no****@nodomain.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
Ok, I've never done n-Tier development and I'm getting confused...

Assuming I have a business layer and a data access layer that may be
running on different machines, how does my business layer know where my
data access layer is running? What is it I have to do in the business
layer that "creates" the data access layer on the other server?

Second, what do I pass between my business layer and my data access
layer? Should I be returning a dataset from the data access layer to the
business layer and letting the business layer convert it in to business
objects, or should my data access layer return business objects?

For example, assume my business layer deals with "Client" objects.
Should my business layer ask my data access layer to return it a
"client" object, leaving the data access layer to determine what that
involves, or does my business layer ask the data access layer for some
information from tables and then the business layer builds the client
object from the returned dataset(s). If so, who builds the SQL, which I
thought would be a DAL function.

As you can probably tell, I could do with a simple (but practical)
tutorial on n-Tier development... anyone know of a good one as it
relates to DESKTOP based applications. Unfortunately, this app I'm
working on is not a web based app.

Thanks
Steve



Jan 30 '06 #7

P: n/a
CMM
To clarify further.... I'm talking about "round trips" here. Their affect on
your LAN. Your LAN's affect on your app's round trips. And, the fact that a
3-tiered design solves this neatly. I agree that the same amount of data has
to pass between an "extra" layer and that seems inefficient. The savings are
realized because your DAL and DB communicate separate from your LAN and the
trouble of "round trips" is vaporized.

If you have a small office with 10 people each connected to their own
dedicated port on a switch... then my argument does not apply (though I
could argue that it still does because of web browsing e-mail, etc). But, if
your company grows (it could happen!... if you're lucky!... it's happened to
me!) you're soon stuck with a badly performing 2-tiered app that needs to be
rewritten. It should have been written properly from the beginning
(3-tiered)! ;-)
"CMM" <cm*@nospam.com> wrote in message
news:ed****************@TK2MSFTNGP12.phx.gbl...
I know what you're saying... but I think you're missing my point...

Talking about desktop WindowsForms apps here...

You're off in your description of the "double-communication" (though I see
what you mean). You have to think about how Ethernet works. In a 2-tiered
app four updates sent to the database BROADCASTS eight (!) trips across
YOUR ENTIRE LAN. This affects EVERY SINGLE user's workstation in your LAN.
Isn't it better for you to just send *one* message and let DAL and DB talk
to each other isolated and do their little 4-command conversation?

You have to take a step back and think about this... The client
workstation and the LAN-in-general are used for other things not just
*your app.* There's web browsing going on, e-mailing being done, and Joe
in the next cubicle downloading the VS2005 4 GB ISO file from
msdn.microsoft.com. I'd rather a bunch of INSERT/UPDATE statements happen
between the DAL Server and the DB Server (with the DAL on the same machine
as the DB or through a dedicated switch- so the LAN at large is not
affected).

I think it is. In almost every single situation.

[Workstation]
|
<dataset with changes>
|
[App Server (DAL/Validation)]
| | | |
<update statements>
| | | |
[Database Server]
P.S. I don't advocate 3-tiered remoting between ASP.NET and the DB. In
this case the Web Server and the DB Server should be hooked (and switched)
together and communication between them is isolated and super-fast (if
they're not on the same machine to begin with which a lot people do too!).
The LAN caveats that I describe do not apply in this set-up as they're
already Server-to-Server.

"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:%2***************@TK2MSFTNGP12.phx.gbl...
CMM,

Altough we completely agree about what you write about encapulation and
mixing this up with Tiers. Is in my opinion your calculation not correcte
and the way you tell that a real physical Tier needed as well not.

To communicate with the middle tier on that seperate computer, you have
to communicate as well with that middle tier. However now it has to do it
twice, one time on your so called 1Gb line and the same as before on your
100Mb line in your sample. The clientcomputer (which is not a terminal)
need the same amount of information and has the same amount of updates.

Therefore there is only an extra piece of datacommunication introduced.
The transport of data on your 1Gb line.

For me the multitier is right in the Terminal application situation (not
windowsclient emulating). In the windowsform situation I see no
advantages, while this Terminal situated 3 tier is already done by a
classic ASP or ASPNET application where the browser functions in a way as
a Terminal and the application as a middle tier.

By the way probably before 1996 multi tier were more common because it is
a very good practise on a real Terminal based computer as Unix and other
Mainframes.

Just my thought,

Cor

"CMM" <cm*@nospam.com> schreef in bericht
news:ej**************@TK2MSFTNGP09.phx.gbl...
Don't listen to that other poster. I'll give you a really simple example
on why programmers in the last five years have lost their minds.... and
have forgotten all the lessons a lot of us learned in the 90's.

What developers call "tiers" nowadays, I call simple "encapsulation"....
NOT TIERS. Somewhere a mass hypnosis has taken root across the
development world concerning this.

Here's an example:

1) Supposse your DAL is on the client machine like the other user
recommends (making it a 2-tiered App). You have a dataset where you've
changed 10 rows. Calling Update on a DataAdapter with this dataset will
result in your update stored proc (or update sql) being called 10 times!
That's 10 network round trips.... across a busy 100-megabit network!
2) Even more likely you've changed one record in one table and 1 record
in 3 other related child tables (Employe--EmployeAddresses--etc.).
That's 4 round trips. Your app is now a VERY CHATTY application. A
network's nightmare.
3) In a true N-Tier structure (a 3-tiered App where the DAL is an
another machine) there's only ONE round trip with your DAL.
4) Now, your DAL and DB servers are connected via 1-gigabit(!)
connection....(this is common)...and connected to each other via a
dedicated switch (so their conversations don't swamp the network the way
your old 2-tiered rinky dink app did).
5) ...Or even better are on the SAME server. The round trips don't
matter AT ALL.
6) Now imagine that your client app needs to run on a simple VPN with an
office overseas. Your old 2-tiered rinky dink app is TOTALLY UNUSABLE
and not much better than your employees using an Access MDB on shared
workgroup server a la Windows 3.1.

Developers think that because they put their data access in a separate
files that they're code warriors and doing something special. In fact,
they're not doing much at all except achieving nice encapsulation
(always a good practice!). They're creating simple 2-tiered apps that
people were coding in 1996 and suffering later for it.

P.S.
ADO.NET 2.0 with SQL Server 2005 introduces "batch updating" which
addresses some of these concerns. But there are HUGE caveats with batch
updating that render it almost useless (like returning Id's from
INSERTS, etc) and almost always require a "rescan" of the affected
tables... rendering moot any performance gains gotten by using batch
updating. Again, TRUE N-TIER development is the answer here.

P.P.S.
You use remoted objects quite easily.... (and building your own
barebones remoting host is super-duper easy... but, if you need object
pooling and stuff like that you'll need to run them in IIS or Windows
Server Component Services).

Dim o As IContactsService =
Activator.GetObject(GetType(IContactsService), serverUri)

where IContactsService is an Interface in a lightweight DLL that exists
on the server and client. Optionally you can put the server components
directly on the client.

Check out these links
-http://www.thinktecture.com/Resources/RemotingFAQ/default.html
-http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/introremoting.asp

"Steve Barnett" <no****@nodomain.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
Ok, I've never done n-Tier development and I'm getting confused...

Assuming I have a business layer and a data access layer that may be
running on different machines, how does my business layer know where my
data access layer is running? What is it I have to do in the business
layer that "creates" the data access layer on the other server?

Second, what do I pass between my business layer and my data access
layer? Should I be returning a dataset from the data access layer to
the business layer and letting the business layer convert it in to
business objects, or should my data access layer return business
objects?

For example, assume my business layer deals with "Client" objects.
Should my business layer ask my data access layer to return it a
"client" object, leaving the data access layer to determine what that
involves, or does my business layer ask the data access layer for some
information from tables and then the business layer builds the client
object from the returned dataset(s). If so, who builds the SQL, which I
thought would be a DAL function.

As you can probably tell, I could do with a simple (but practical)
tutorial on n-Tier development... anyone know of a good one as it
relates to DESKTOP based applications. Unfortunately, this app I'm
working on is not a web based app.

Thanks
Steve



Jan 30 '06 #8

P: n/a
CMM,

I see that you have well thought about it. However trying to get you out of
a loop you are in my idea in (or maybe I am in it and can you show me that).

What does it change when I communicate on whatever line to a middle Tier
DataServer or direct to the EndDataServer?

I wrote already that the needed information and sended updates stays for the
clients the same to whatever of those two and that goes over the same line
how small it is and what protocoll to detect if it is for the right client
is used.

You use your 1Gb line for probably the smallest amount of data and it is
even clean, so probably is no more than 2Mb used, assuming that you don't
use it for things as backup, replication etc.

In your picture

[Workstations] <dataset> Or whatever information transportcontainer
||||||||||||||||||||||
[App Server (DAL/Validation)]
| |
<retrieve/update statements>
| |
[Database Server]

Or tell me what I miss?

Cor

"CMM" <cm*@nospam.com> schreef in bericht
news:ed****************@TK2MSFTNGP12.phx.gbl...
I know what you're saying... but I think you're missing my point...

Talking about desktop WindowsForms apps here...

You're off in your description of the "double-communication" (though I see
what you mean). You have to think about how Ethernet works. In a 2-tiered
app four updates sent to the database BROADCASTS eight (!) trips across
YOUR ENTIRE LAN. This affects EVERY SINGLE user's workstation in your LAN.
Isn't it better for you to just send *one* message and let DAL and DB talk
to each other isolated and do their little 4-command conversation?

You have to take a step back and think about this... The client
workstation and the LAN-in-general are used for other things not just
*your app.* There's web browsing going on, e-mailing being done, and Joe
in the next cubicle downloading the VS2005 4 GB ISO file from
msdn.microsoft.com. I'd rather a bunch of INSERT/UPDATE statements happen
between the DAL Server and the DB Server (with the DAL on the same machine
as the DB or through a dedicated switch- so the LAN at large is not
affected).

I think it is. In almost every single situation.

[Workstation]
|
<dataset with changes>
|
[App Server (DAL/Validation)]
| | | |
<update statements>
| | | |
[Database Server]
P.S. I don't advocate 3-tiered remoting between ASP.NET and the DB. In
this case the Web Server and the DB Server should be hooked (and switched)
together and communication between them is isolated and super-fast (if
they're not on the same machine to begin with which a lot people do too!).
The LAN caveats that I describe do not apply in this set-up as they're
already Server-to-Server.

"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:%2***************@TK2MSFTNGP12.phx.gbl...
CMM,

Altough we completely agree about what you write about encapulation and
mixing this up with Tiers. Is in my opinion your calculation not correcte
and the way you tell that a real physical Tier needed as well not.

To communicate with the middle tier on that seperate computer, you have
to communicate as well with that middle tier. However now it has to do it
twice, one time on your so called 1Gb line and the same as before on your
100Mb line in your sample. The clientcomputer (which is not a terminal)
need the same amount of information and has the same amount of updates.

Therefore there is only an extra piece of datacommunication introduced.
The transport of data on your 1Gb line.

For me the multitier is right in the Terminal application situation (not
windowsclient emulating). In the windowsform situation I see no
advantages, while this Terminal situated 3 tier is already done by a
classic ASP or ASPNET application where the browser functions in a way as
a Terminal and the application as a middle tier.

By the way probably before 1996 multi tier were more common because it is
a very good practise on a real Terminal based computer as Unix and other
Mainframes.

Just my thought,

Cor

"CMM" <cm*@nospam.com> schreef in bericht
news:ej**************@TK2MSFTNGP09.phx.gbl...
Don't listen to that other poster. I'll give you a really simple example
on why programmers in the last five years have lost their minds.... and
have forgotten all the lessons a lot of us learned in the 90's.

What developers call "tiers" nowadays, I call simple "encapsulation"....
NOT TIERS. Somewhere a mass hypnosis has taken root across the
development world concerning this.

Here's an example:

1) Supposse your DAL is on the client machine like the other user
recommends (making it a 2-tiered App). You have a dataset where you've
changed 10 rows. Calling Update on a DataAdapter with this dataset will
result in your update stored proc (or update sql) being called 10 times!
That's 10 network round trips.... across a busy 100-megabit network!
2) Even more likely you've changed one record in one table and 1 record
in 3 other related child tables (Employe--EmployeAddresses--etc.).
That's 4 round trips. Your app is now a VERY CHATTY application. A
network's nightmare.
3) In a true N-Tier structure (a 3-tiered App where the DAL is an
another machine) there's only ONE round trip with your DAL.
4) Now, your DAL and DB servers are connected via 1-gigabit(!)
connection....(this is common)...and connected to each other via a
dedicated switch (so their conversations don't swamp the network the way
your old 2-tiered rinky dink app did).
5) ...Or even better are on the SAME server. The round trips don't
matter AT ALL.
6) Now imagine that your client app needs to run on a simple VPN with an
office overseas. Your old 2-tiered rinky dink app is TOTALLY UNUSABLE
and not much better than your employees using an Access MDB on shared
workgroup server a la Windows 3.1.

Developers think that because they put their data access in a separate
files that they're code warriors and doing something special. In fact,
they're not doing much at all except achieving nice encapsulation
(always a good practice!). They're creating simple 2-tiered apps that
people were coding in 1996 and suffering later for it.

P.S.
ADO.NET 2.0 with SQL Server 2005 introduces "batch updating" which
addresses some of these concerns. But there are HUGE caveats with batch
updating that render it almost useless (like returning Id's from
INSERTS, etc) and almost always require a "rescan" of the affected
tables... rendering moot any performance gains gotten by using batch
updating. Again, TRUE N-TIER development is the answer here.

P.P.S.
You use remoted objects quite easily.... (and building your own
barebones remoting host is super-duper easy... but, if you need object
pooling and stuff like that you'll need to run them in IIS or Windows
Server Component Services).

Dim o As IContactsService =
Activator.GetObject(GetType(IContactsService), serverUri)

where IContactsService is an Interface in a lightweight DLL that exists
on the server and client. Optionally you can put the server components
directly on the client.

Check out these links
-http://www.thinktecture.com/Resources/RemotingFAQ/default.html
-http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/introremoting.asp

"Steve Barnett" <no****@nodomain.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
Ok, I've never done n-Tier development and I'm getting confused...

Assuming I have a business layer and a data access layer that may be
running on different machines, how does my business layer know where my
data access layer is running? What is it I have to do in the business
layer that "creates" the data access layer on the other server?

Second, what do I pass between my business layer and my data access
layer? Should I be returning a dataset from the data access layer to
the business layer and letting the business layer convert it in to
business objects, or should my data access layer return business
objects?

For example, assume my business layer deals with "Client" objects.
Should my business layer ask my data access layer to return it a
"client" object, leaving the data access layer to determine what that
involves, or does my business layer ask the data access layer for some
information from tables and then the business layer builds the client
object from the returned dataset(s). If so, who builds the SQL, which I
thought would be a DAL function.

As you can probably tell, I could do with a simple (but practical)
tutorial on n-Tier development... anyone know of a good one as it
relates to DESKTOP based applications. Unfortunately, this app I'm
working on is not a web based app.

Thanks
Steve



Jan 30 '06 #9

P: n/a
CMM wrote:
I disagree with almost everything you state.
See below for my inline comments:

I'll agree to disagree :) Not everybody can agree on everything, that's
perfectly fine with me. However, I think you mostly misunderstood what I
said.

See my other post. It's all about round trips... and not even about
load-balancing and "high-end stuff." Even a minor app with about 20 users
benefits from a true 3-Tiered design (3-Tiered meaning the DAL is another
machine).

I do use true 3-tiered designs. Yes, obviously there are benefits. You
fail to mention something: the DAL is on another machine than ??? And
where do you assume that ??? is? It sounds to me like you have your BLL
in the client itself (there are no mentions of 2 app servers anywhere in
your other posts - one for DAL and one for BLL). And BTW 3-tiered can
mean a LOT of different things to a lot of people... I've seen MVPs
argue over this just last week...
See my reply to the original poster for more.

Passing DataReaders is horrible (pre .NET 2.0, anyway). Do I need to explain
why? Do people actually still do this?
I didn't say it was my preffered method or anything (nor recommended it)
- just that some people use it. The odd times where I use it it doesn't
go straight to BLL either, there's a "helper/translation class" that
turns it into Business Objects in between (an extra layer). 99.5% of
what I do nowadays is v2.0 :)

Yes. Datasets can behave like busines entities if you wanted them to.
Spending time with ORM is such a waste of time when Typed Datasets do
anything and everything you could hope to accomplish. I like the "Document"
paradigm... where service classes act ON the dataset (validators, data
access, etc) and the dataset is basically dumb. It's clean and modular. I
can change a "validation service" without ever touching the dataset class or
the client application.
That's still a matter of preferences. There are TONS of people which are
REALLY into various ORM tools and would very much disagree with you (be
it NHibernate or others).
As for building SQL, that would be the DAL's function, but it shouldn't
have to build very much... Most queries should be hardcoded really..
Why?
Will someone please explain (and defend!) this fairly common supposition?


Why not use hardcoded queries for most simple stuff? You'd rather build
soem kind of complex on-the-fly query generator instead? Code generation
tools with some good templates generates 95% of this stuff very well
(never find bugs in it either). I don't see why you'd want to have to
even bother generating them dynamically. I'm not sure what your point is
really.
.
The only queries I usually generate are the complex ones - those for
complex searches or custom paging and such.
Seems to me that these exact type of queries are the ONLY queries that
actually benefit from stored procedures / functions (because of compliation
and query plans and optimization and stuff like that).


Actually, after much toying around with various sprocs (and reading
other ppl's in-depth articles and similar tests on this, and a lot of
chat with our DBA), most of such queries (in our apps at least) DON'T
benefit from that, mainly because they can't get cached (some things
can't take parms or are too complex and must be generated by a sproc
then use sp_executeSql... long story, not even going there) - exactly
the inverse of what you said...
But this....
Most queries (plain CRUD operations on the DB) are static (hand coded or
generated by some automation tool).
is retarded. Wrapping up *every* little INSERT/UPDATE simple SELECT in a
stored proc is retarded. It's not that its "wrong"... I'm not against it and
in fact I even like it (it seems untuitively "orderly")....it's just that 1)
it doesn't accomplish much and 2) it's totally expensive and unmanageable in
the long run unless you have a whole dedicated DBA team. It's not worth the
effort for the little payoff that it provides.


Who's talking about sprocs here? (that'd be you...) I'm talking about
static/hardcoded parameterized queries in the DAL (again, all generated
by some codegen - no work at all)
Whether it's a web app or a desktop app, the n-tier principles are mainly
the same, you just tend to use/connect to the middleware differently.


Not true. In n-Tier the middleware is stateless. This is a big design
difference. However, invocation is not all that different and it sounds
scarier than it really is (ooohh remoting host exe-- what is that? I'm
scared.).


Who said anything about the middleware NOT being stateless? I don't see
what you're trying to say here... You're making assumptions or something
again...
If you seach on codeproject.com I'm sure you'll find several n-tier dev
articles.


Jan 30 '06 #10

P: n/a
CMM wrote:
Don't listen to that other poster. I'll give you a really simple example on
why programmers in the last five years have lost their minds.... and have
forgotten all the lessons a lot of us learned in the 90's.

Yeah, ignore me based on you've misunderstood ~100% of what I said?
Okie... If you say so...
What developers call "tiers" nowadays, I call simple "encapsulation".... NOT
TIERS. Somewhere a mass hypnosis has taken root across the development world
concerning this.

Here's an example:

1) Supposse your DAL is on the client machine like the other user recommends
(making it a 2-tiered App). You have a dataset where you've changed 10 rows.
When did I EVER recommend putting it on the client (hint: NEVER). This
would be a 2 layer app, but it's not what I recommended whatsoever...
Calling Update on a DataAdapter with this dataset will result in your update
stored proc (or update sql) being called 10 times! That's 10 network round
trips.... across a busy 100-megabit network!
2) Even more likely you've changed one record in one table and 1 record in 3
other related child tables (Employe--EmployeAddresses--etc.). That's 4 round
trips. Your app is now a VERY CHATTY application. A network's nightmare.
3) In a true N-Tier structure (a 3-tiered App where the DAL is an another
machine) there's only ONE round trip with your DAL.
4) Now, your DAL and DB servers are connected via 1-gigabit(!)
connection....(this is common)...and connected to each other via a dedicated
switch (so their conversations don't swamp the network the way your old
2-tiered rinky dink app did).
5) ...Or even better are on the SAME server. The round trips don't matter AT
ALL.
6) Now imagine that your client app needs to run on a simple VPN with an
office overseas. Your old 2-tiered rinky dink app is TOTALLY UNUSABLE and
not much better than your employees using an Access MDB on shared workgroup
server a la Windows 3.1.

Developers think that because they put their data access in a separate files
that they're code warriors and doing something special. In fact, they're not
doing much at all except achieving nice encapsulation (always a good
practice!). They're creating simple 2-tiered apps that people were coding in
1996 and suffering later for it.

P.S.
ADO.NET 2.0 with SQL Server 2005 introduces "batch updating" which addresses
some of these concerns. But there are HUGE caveats with batch updating that
render it almost useless (like returning Id's from INSERTS, etc) and almost
always require a "rescan" of the affected tables... rendering moot any
performance gains gotten by using batch updating. Again, TRUE N-TIER
development is the answer here.

P.P.S.
You use remoted objects quite easily.... (and building your own barebones
remoting host is super-duper easy... but, if you need object pooling and
stuff like that you'll need to run them in IIS or Windows Server Component
Services).

Dim o As IContactsService =
Activator.GetObject(GetType(IContactsService), serverUri)

where IContactsService is an Interface in a lightweight DLL that exists on
the server and client. Optionally you can put the server components directly
on the client.

Check out these links
-http://www.thinktecture.com/Resources/RemotingFAQ/default.html
-http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/introremoting.asp

Jan 30 '06 #11

P: n/a
CMM
"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:eg*************@TK2MSFTNGP10.phx.gbl...
CMM,

I see that you have well thought about it. However trying to get you out
of a loop you are in my idea in (or maybe I am in it and can you show me
that).

What does it change when I communicate on whatever line to a middle Tier
DataServer or direct to the EndDataServer?


When you communicate with the middle tier you're sending a
dataset-wth-changes in one network call over the LAN. This translates into
exactly two broadcasts (1 there, and 1 back.... a rountrip) no matter how
many records are in the dataset.

vs.

When you communicate with the data server directly you're sending sql
insert/update commands over several network calls. For instance, submitting
10 changed rows causes 20 broadcasts across your LAN.

It's as simple as that. Coupled with that fact that your LAN is used for
many other things (web, e-mail, etc.)- not just your app- I think the first
solution (3-tiered) is always the more efficient. It doesn't make much
difference with just a few users... but it also doesn't hurt much either!...
and it makes your app a lot more robust and easier to maintain in the
long-run.
Jan 30 '06 #12

P: n/a
CMM
Sorry. I misunderstood your original post. I apologize.
Jan 30 '06 #13

P: n/a
CMM
Also, to correct your diagram...

In a 3-tiered design....

[Workstation(s)] <dataset> Or whatever information transportcontainer
|||||||||||||||||||||| (LAN)
[App Server (DAL/Validation)] <retrieve/update statements>
|||||||||||||||||||||||||||||||||||||||||||||||| (NOT-LAN)
[Database Server]

Also, if the DAL was on the same machine as the workstations (2-tiered
design) the diagram changes to this:

[Workstation(s) /w DAL] <retrieve/update statements>
|||||||||||||||||||||||||||||||||||||||||||||||| (LAN)
[Database Server]

Communication with the DAL doesn't get diagramed because you're just passing
a simple reference to the Dataset to the DAL (there's no serialization or
marshalling involved). In fact when you see authors recommend calling
GetChanges() before passing data to the DAL.... this is ONLY for TRUE
n-tiered design... not when your DAL is on the client machine.
"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:eg*************@TK2MSFTNGP10.phx.gbl...
CMM,

I see that you have well thought about it. However trying to get you out
of a loop you are in my idea in (or maybe I am in it and can you show me
that).

What does it change when I communicate on whatever line to a middle Tier
DataServer or direct to the EndDataServer?

I wrote already that the needed information and sended updates stays for
the clients the same to whatever of those two and that goes over the same
line how small it is and what protocoll to detect if it is for the right
client is used.

You use your 1Gb line for probably the smallest amount of data and it is
even clean, so probably is no more than 2Mb used, assuming that you don't
use it for things as backup, replication etc.

In your picture

[Workstations] <dataset> Or whatever information transportcontainer
||||||||||||||||||||||
[App Server (DAL/Validation)]
| |
<retrieve/update statements>
| |
[Database Server]

Or tell me what I miss?

Cor

"CMM" <cm*@nospam.com> schreef in bericht
news:ed****************@TK2MSFTNGP12.phx.gbl...
I know what you're saying... but I think you're missing my point...

Talking about desktop WindowsForms apps here...

You're off in your description of the "double-communication" (though I
see what you mean). You have to think about how Ethernet works. In a
2-tiered app four updates sent to the database BROADCASTS eight (!) trips
across YOUR ENTIRE LAN. This affects EVERY SINGLE user's workstation in
your LAN. Isn't it better for you to just send *one* message and let DAL
and DB talk to each other isolated and do their little 4-command
conversation?

You have to take a step back and think about this... The client
workstation and the LAN-in-general are used for other things not just
*your app.* There's web browsing going on, e-mailing being done, and Joe
in the next cubicle downloading the VS2005 4 GB ISO file from
msdn.microsoft.com. I'd rather a bunch of INSERT/UPDATE statements happen
between the DAL Server and the DB Server (with the DAL on the same
machine as the DB or through a dedicated switch- so the LAN at large is
not affected).

I think it is. In almost every single situation.

[Workstation]
|
<dataset with changes>
|
[App Server (DAL/Validation)]
| | | |
<update statements>
| | | |
[Database Server]
P.S. I don't advocate 3-tiered remoting between ASP.NET and the DB. In
this case the Web Server and the DB Server should be hooked (and
switched) together and communication between them is isolated and
super-fast (if they're not on the same machine to begin with which a lot
people do too!). The LAN caveats that I describe do not apply in this
set-up as they're already Server-to-Server.

"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:%2***************@TK2MSFTNGP12.phx.gbl...
CMM,

Altough we completely agree about what you write about encapulation and
mixing this up with Tiers. Is in my opinion your calculation not
correcte and the way you tell that a real physical Tier needed as well
not.

To communicate with the middle tier on that seperate computer, you have
to communicate as well with that middle tier. However now it has to do
it twice, one time on your so called 1Gb line and the same as before on
your 100Mb line in your sample. The clientcomputer (which is not a
terminal) need the same amount of information and has the same amount of
updates.

Therefore there is only an extra piece of datacommunication introduced.
The transport of data on your 1Gb line.

For me the multitier is right in the Terminal application situation (not
windowsclient emulating). In the windowsform situation I see no
advantages, while this Terminal situated 3 tier is already done by a
classic ASP or ASPNET application where the browser functions in a way
as a Terminal and the application as a middle tier.

By the way probably before 1996 multi tier were more common because it
is a very good practise on a real Terminal based computer as Unix and
other Mainframes.

Just my thought,

Cor

"CMM" <cm*@nospam.com> schreef in bericht
news:ej**************@TK2MSFTNGP09.phx.gbl...
Don't listen to that other poster. I'll give you a really simple
example on why programmers in the last five years have lost their
minds.... and have forgotten all the lessons a lot of us learned in the
90's.

What developers call "tiers" nowadays, I call simple
"encapsulation".... NOT TIERS. Somewhere a mass hypnosis has taken root
across the development world concerning this.

Here's an example:

1) Supposse your DAL is on the client machine like the other user
recommends (making it a 2-tiered App). You have a dataset where you've
changed 10 rows. Calling Update on a DataAdapter with this dataset will
result in your update stored proc (or update sql) being called 10
times! That's 10 network round trips.... across a busy 100-megabit
network!
2) Even more likely you've changed one record in one table and 1 record
in 3 other related child tables (Employe--EmployeAddresses--etc.).
That's 4 round trips. Your app is now a VERY CHATTY application. A
network's nightmare.
3) In a true N-Tier structure (a 3-tiered App where the DAL is an
another machine) there's only ONE round trip with your DAL.
4) Now, your DAL and DB servers are connected via 1-gigabit(!)
connection....(this is common)...and connected to each other via a
dedicated switch (so their conversations don't swamp the network the
way your old 2-tiered rinky dink app did).
5) ...Or even better are on the SAME server. The round trips don't
matter AT ALL.
6) Now imagine that your client app needs to run on a simple VPN with
an office overseas. Your old 2-tiered rinky dink app is TOTALLY
UNUSABLE and not much better than your employees using an Access MDB on
shared workgroup server a la Windows 3.1.

Developers think that because they put their data access in a separate
files that they're code warriors and doing something special. In fact,
they're not doing much at all except achieving nice encapsulation
(always a good practice!). They're creating simple 2-tiered apps that
people were coding in 1996 and suffering later for it.

P.S.
ADO.NET 2.0 with SQL Server 2005 introduces "batch updating" which
addresses some of these concerns. But there are HUGE caveats with batch
updating that render it almost useless (like returning Id's from
INSERTS, etc) and almost always require a "rescan" of the affected
tables... rendering moot any performance gains gotten by using batch
updating. Again, TRUE N-TIER development is the answer here.

P.P.S.
You use remoted objects quite easily.... (and building your own
barebones remoting host is super-duper easy... but, if you need object
pooling and stuff like that you'll need to run them in IIS or Windows
Server Component Services).

Dim o As IContactsService =
Activator.GetObject(GetType(IContactsService), serverUri)

where IContactsService is an Interface in a lightweight DLL that exists
on the server and client. Optionally you can put the server components
directly on the client.

Check out these links
-http://www.thinktecture.com/Resources/RemotingFAQ/default.html
-http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/introremoting.asp

"Steve Barnett" <no****@nodomain.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
> Ok, I've never done n-Tier development and I'm getting confused...
>
> Assuming I have a business layer and a data access layer that may be
> running on different machines, how does my business layer know where
> my data access layer is running? What is it I have to do in the
> business layer that "creates" the data access layer on the other
> server?
>
> Second, what do I pass between my business layer and my data access
> layer? Should I be returning a dataset from the data access layer to
> the business layer and letting the business layer convert it in to
> business objects, or should my data access layer return business
> objects?
>
> For example, assume my business layer deals with "Client" objects.
> Should my business layer ask my data access layer to return it a
> "client" object, leaving the data access layer to determine what that
> involves, or does my business layer ask the data access layer for some
> information from tables and then the business layer builds the client
> object from the returned dataset(s). If so, who builds the SQL, which
> I thought would be a DAL function.
>
> As you can probably tell, I could do with a simple (but practical)
> tutorial on n-Tier development... anyone know of a good one as it
> relates to DESKTOP based applications. Unfortunately, this app I'm
> working on is not a web based app.
>
> Thanks
> Steve
>



Jan 30 '06 #14

P: n/a
CMM
"Steve Barnett" <no****@nodomain.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
Ok, I've never done n-Tier development and I'm getting confused...

Assuming I have a business layer and a data access layer that may be
running on different machines, how does my business layer know where my
data access layer is running? What is it I have to do in the business
layer that "creates" the data access layer on the other server?

Second, what do I pass between my business layer and my data access layer?
Should I be returning a dataset from the data access layer to the business
layer and letting the business layer convert it in to business objects, or
should my data access layer return business objects?
Your DAL should return datasets to the BL. Your BL should return your
complex entity objects using whatever ORM technique you implement
yourself.... this is a A LOT of work.... I personally like to use Typed
Datasets across ALL layers... the BL uses a set of validator classes to
validate and enforce business rules on the dataset. And the DAL uses
DataAdapters to submit dataset changes to the database.

This sort of Document / Validation / Rules / Transform paradigm "act on" the
dataset.... the dataset is dumb.... it is similar to (XML, XSD enforcement,
XSLT if you know what I mean). Datasets don't even have to look like the
Tables in the database at all. Your Contact tables has field labeled
Company_Name_En and another one labeled Company_Name_zh-CN for
globalization.... your Dataset can simply have a CompanyName field. You do
this via DataAdapters TableMappings feature which is exactly what you'd be
doing using your own (super-tedious and messy) ORM code.

I would also argue that Datasets (Typed Datasets to be precise) function
very well as "entities"... once you realize that Typed Datasets have NOTHING
TO DO with "databases" (they're agnostic... simply a a strongly typed array
on steriods) and are just a "collection of entities" and there's no shame
for instance in a Dataset containing a Single Contact object (row). In fact
Typed Datasets solve a lot of limitations of ORM that take a lot of manual
coding (like implementing Undo, sorting, raising events when values change,
etc etc).

However if you want your entities to have built-in encapsulated rules
(something which I again argue belongs OUTSIDE of the entities) then full
blown ORM is the way you ought to go (almost never in my opinion).

For example, assume my business layer deals with "Client" objects. Should
my business layer ask my data access layer to return it a "client" object,
leaving the data access layer to determine what that involves, or does my
business layer ask the data access layer for some information from tables
and then the business layer builds the client object from the returned
dataset(s). If so, who builds the SQL, which I thought would be a DAL
function.
The DAL builds the SQL or it calls an SP with the SQL already in it. Your BL
is responsible for validating the data and enforcing business ruless.... and
optionally transforming the data to and from a complex object for the client
to use (see my comments above).

As you can probably tell, I could do with a simple (but practical)
tutorial on n-Tier development... anyone know of a good one as it relates
to DESKTOP based applications. Unfortunately, this app I'm working on is
not a web based app.

Thanks
Steve

Jan 30 '06 #15

P: n/a
CMM
.... and in short- I agree with you that there is little benefit in having
the DAL and BL on separate servers. I thought you were referring to the
client workstations (which should not contain the DAL or BL as is the common
(and lazy) practice).
"CMM" <cm*@nospam.com> wrote in message
news:%2***************@TK2MSFTNGP09.phx.gbl...
Sorry. I misunderstood your original post. I apologize.

Jan 31 '06 #16

P: n/a
CMM,

We are talking about physical seperated Tiers why do you switch to Data
Access Layers. With DAL you only are physical replacing references, that was
something we where not talking about. It goes a very very very little bit
slower, however the encapsulated design has its advantages. Therefore that
going slower will normally be gained back in more speed by the fact that the
design is better and therefore there are no strange things in your programs
which has everywhere its dataaccess points.

However, we where talking about physical seperated Tiers, I don't see why
you come now with DAL. Your point was that a DAL was not by definition
direct a physical Tier. However the last years used as are they the same as
discussed, with that I did agree, now using the DAL in the discussions does
it in my opinion not make it really clear.

The process goes in my idea as this.

The client sents (using different layers) as much validated datarows which
have rowstate changes to the DataBase Server. Here the datarows are
processed and sent information back to the client. The information can be
processed or not done, this is told by a returned value. If there is an
error the only one who can resolve the error than it is the client.

I don't see where your seperated phycical middle tier speed up this process
seen from the technique of the LAN.

I know what is a Lan and the behaviour from differnt types. I have
implemented almost every type LAN from physical thin coax ethernet based
until now wireless ethernet and all types as ARC, TokenRing, Collision
Detect/Collision Avoid and BroadBand. This before you think that I don't
know what that is. In that to speed up, I have used software as well as
hardware routers in the Collision ones.

I am still curious what can be done by your so called application server (to
be clear and repeating, in a windowforms intelligent client situation. In
Unix, mainframe or any other kind of situation with not intelligent clients,
the middle tiers are a must in my opinion).

Cor
Jan 31 '06 #17

P: n/a
CMM
"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:Ot**************@TK2MSFTNGP10.phx.gbl...
CMM,

We are talking about physical seperated Tiers why do you switch to Data
Access Layers. With DAL you only are physical replacing references, that
was something we where not talking about. It goes a very very very little
bit

<snip>

Because I'm trying to make the point that the DAL belongs in a physical tier
separated from the client. That's the only point I'm trying to make. I think
I made it.

I'm not talking about anything else (BL, validation, rules, whatever...
which can be anywhere depending on requirements).

I don't really understand the rest of your post. Sorry.
Jan 31 '06 #18

P: n/a
CMM,

Now I see how you create a lot of Lan traffic,
I'm not talking about anything else (BL, validation, rules, whatever...
which can be anywhere depending on requirements).

This has in your situation to be communicated over the Lan everytime with
the client, while when the DAL and Busines Layer is implemented on the
client side there is no extra trafic. You cannot fix errors by default.
Otherwise it could be already done in the client before sending.

Cor
Jan 31 '06 #19

P: n/a
CMM
Not sure I understand your post...

Validation and business rules... this is tricky:
In true n-tier you would also divide the business rules and validation
across all three tiers (client, middle, db)... like this:

Simple Validation Layer (on the client)
- Simple validation can happen on the client machine (IsDate,
IsStringTooLong, IsNumberGreaterThanZero, etc etc.). Preferably you would
put this in a layer of its own (layer=classes not tier) and not hardcode it
in the UI. It depends on the requirements and your preferences. I like
encapsulation.

You can also implement some "atomic" business rules that concern the entity
and only the entity... like (Contact.DeliveryMethod=Email And
Contact.Email="") = ERROR.

Complex Rules Layer
- Business Rules are enforced in the physical middle tier. Why? Well,
because sometimes (often) they call for extra communication with the DB and
validating against data that the client machine does not have and doesn't
care about! For instance, "Did some *other* change in the database
invalidate this proposed update." This extra DB communication (round trips!)
should happen between the MiddleTier and the DB and not through the LAN!

Don't you agree?

You have App-A that allows a secretary to edit a contact's information. This
app has no knowledge of a Contact's Magazine Subscriptions (that's handled
by some other app somewhere else). Say the secretary submits a record change
that makes a Contact's Email="". You have a business rule in the MiddleTier
that checks the database's ContactSubscriptions table to make sure the user
hasn't subscribed to any "E-mail subscriptions." Why should the App-A client
have to do this? How can it validate it? Should it query the database for
subscriptions it otherwise doesn't care about??? That's a LAN broadcast!!!!
Why not just put that in the MiddleTier where it belongs! If the contact has
a Magazine Subscription, the MiddleTier BL rejects the change (doesn't pass
it along to the DAL).

DB Constraints
- Sometimes this duplicates business rules at times. There's nothing wrong
with that. Generally data-entegrity and data-quality merit it. Often
though... flexibility dictates that constraints NOT be used to enforce
"business rules" per se.... but rather data-integrity. Of course there's a
grey area here.. and it takes thoughtfulness to think some of this stuff
through. Like, "will there be times when this constraint should not be
enforced?"... if so, it shouldn't be a constraint... it should be a rule in
the middle tier.
Jan 31 '06 #20

P: n/a
CMM,

I wrote about this,
Why? Well, because sometimes (often) they call for extra communication
with the DB and validating against data that the client machine does not
have and doesn't care about! For instance, "Did some *other* change in the
database invalidate this proposed update." This extra DB communication
(round trips!) should happen between the MiddleTier and the DB and not
through the LAN!

Don't you agree?

How can you solve this in the Middle Tier without interaction from the user.
The least you have to show is ("not accepted")

These errors are by the way called concurrency errors.
There is given information back by the DataBaseServer in the errorpart of
the datarow if this happens.

http://msdn2.microsoft.com/en-us/lib....rowerror.aspx

What would your action be in the Physical Middle Tier without action from
the User?

Cor
Jan 31 '06 #21

P: n/a
CMM
"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:et**************@TK2MSFTNGP14.phx.gbl...
How can you solve this in the Middle Tier without interaction from the
user.
The least you have to show is ("not accepted")
Same way you would solve (or not solve) it if the BL and DAL where on the
client machine. Only:

in the n-tier scenerio the process goes like this (look at the LAN steps):
1) There is ONE call to the MiddleTier (LAN).
2) Several calls between the MiddleTier and DB (NOT LAN).
3) "ERROR: reason(s)"
3) ONE call for the user to fix (LAN).
4) Several calls between the MiddleTier and DB (LAN).

in your 2-tiered app it goes like this

1) Several calls back and forth to the DB (LAN).<-- expensive
2) "ERROR: reason(s)"
3) Several calls for the user to fix back and forth to the DB (LAN).<--
expensive

Remember... in my example, in order to validate the database needs to be
queried for "subscriptions" because this data is NOT part of the original
dataset.

LAN= lots of stuff going on here (100mbit bandwidth shared by everybody...
e-mail, browsing, downloading, chatting, fileshare browsing)
NOT LAN= BL/DAL on same DB machine or via a high-speed switch.

These errors are by the way called concurrency errors.
No, not really... not in my example anyway. The error was triggered by a
table that has not changed... but rather contains data that that particular
app has no knowledge of at all and couldn't care less about. This is not
concurrency. This is a business rule.
There is given information back by the DataBaseServer in the errorpart of
the datarow if this happens.

http://msdn2.microsoft.com/en-us/lib....rowerror.aspx
I love this feature of datasets. Not only can the middle tier set an error
on a dataset row but also on a specific column!.... I love it.

What would your action be in the Physical Middle Tier without action from
the User?
What would it be if the BL or DAL or whatever was on the client? Same thing
here.... though I don't think you're understanding what I'm saying.

Cor

Jan 31 '06 #22

P: n/a
CMM
Oops... Step 4 in my example should be
4) Several calls between the MiddleTier and DB (*NOT* LAN).

"CMM" <cm*@nospam.com> wrote in message
news:OM*************@TK2MSFTNGP12.phx.gbl...
"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:et**************@TK2MSFTNGP14.phx.gbl...
How can you solve this in the Middle Tier without interaction from the
user.
The least you have to show is ("not accepted")


Same way you would solve (or not solve) it if the BL and DAL where on the
client machine. Only:

in the n-tier scenerio the process goes like this (look at the LAN steps):
1) There is ONE call to the MiddleTier (LAN).
2) Several calls between the MiddleTier and DB (NOT LAN).
3) "ERROR: reason(s)"
3) ONE call for the user to fix (LAN).
4) Several calls between the MiddleTier and DB (LAN).

in your 2-tiered app it goes like this

1) Several calls back and forth to the DB (LAN).<-- expensive
2) "ERROR: reason(s)"
3) Several calls for the user to fix back and forth to the DB (LAN).<--
expensive

Remember... in my example, in order to validate the database needs to be
queried for "subscriptions" because this data is NOT part of the original
dataset.

LAN= lots of stuff going on here (100mbit bandwidth shared by everybody...
e-mail, browsing, downloading, chatting, fileshare browsing)
NOT LAN= BL/DAL on same DB machine or via a high-speed switch.

These errors are by the way called concurrency errors.


No, not really... not in my example anyway. The error was triggered by a
table that has not changed... but rather contains data that that
particular app has no knowledge of at all and couldn't care less about.
This is not concurrency. This is a business rule.
There is given information back by the DataBaseServer in the errorpart of
the datarow if this happens.

http://msdn2.microsoft.com/en-us/lib....rowerror.aspx


I love this feature of datasets. Not only can the middle tier set an error
on a dataset row but also on a specific column!.... I love it.

What would your action be in the Physical Middle Tier without action from
the User?


What would it be if the BL or DAL or whatever was on the client? Same
thing here.... though I don't think you're understanding what I'm saying.

Cor


Jan 31 '06 #23

P: n/a
I very much appreciate this. I have been following the discussion, trying to
pick out as much as I can, but haven't passed comment as I felt there was
nothing I could contribute to the debate. Its been fascinating and I thank
you all very much for having it is such a civilised and constructive way.

Most useful.

My design actually called for the UI and BL to be on the same machine with
the DAL probably elsewhere, though I also need to cater for them being on
the same (laptop) PC.

Thanks
Steve

"CMM" <cm*@nospam.com> wrote in message
news:ug****************@TK2MSFTNGP10.phx.gbl...
"Steve Barnett" <no****@nodomain.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
Ok, I've never done n-Tier development and I'm getting confused...

Assuming I have a business layer and a data access layer that may be
running on different machines, how does my business layer know where my
data access layer is running? What is it I have to do in the business
layer that "creates" the data access layer on the other server?

Second, what do I pass between my business layer and my data access
layer? Should I be returning a dataset from the data access layer to the
business layer and letting the business layer convert it in to business
objects, or should my data access layer return business objects?


Your DAL should return datasets to the BL. Your BL should return your
complex entity objects using whatever ORM technique you implement
yourself.... this is a A LOT of work.... I personally like to use Typed
Datasets across ALL layers... the BL uses a set of validator classes to
validate and enforce business rules on the dataset. And the DAL uses
DataAdapters to submit dataset changes to the database.

This sort of Document / Validation / Rules / Transform paradigm "act on"
the dataset.... the dataset is dumb.... it is similar to (XML, XSD
enforcement, XSLT if you know what I mean). Datasets don't even have to
look like the Tables in the database at all. Your Contact tables has field
labeled Company_Name_En and another one labeled Company_Name_zh-CN for
globalization.... your Dataset can simply have a CompanyName field. You do
this via DataAdapters TableMappings feature which is exactly what you'd be
doing using your own (super-tedious and messy) ORM code.

I would also argue that Datasets (Typed Datasets to be precise) function
very well as "entities"... once you realize that Typed Datasets have
NOTHING TO DO with "databases" (they're agnostic... simply a a strongly
typed array on steriods) and are just a "collection of entities" and
there's no shame for instance in a Dataset containing a Single Contact
object (row). In fact Typed Datasets solve a lot of limitations of ORM
that take a lot of manual coding (like implementing Undo, sorting, raising
events when values change, etc etc).

However if you want your entities to have built-in encapsulated rules
(something which I again argue belongs OUTSIDE of the entities) then full
blown ORM is the way you ought to go (almost never in my opinion).

For example, assume my business layer deals with "Client" objects. Should
my business layer ask my data access layer to return it a "client"
object, leaving the data access layer to determine what that involves, or
does my business layer ask the data access layer for some information
from tables and then the business layer builds the client object from the
returned dataset(s). If so, who builds the SQL, which I thought would be
a DAL function.


The DAL builds the SQL or it calls an SP with the SQL already in it. Your
BL is responsible for validating the data and enforcing business
ruless.... and optionally transforming the data to and from a complex
object for the client to use (see my comments above).

As you can probably tell, I could do with a simple (but practical)
tutorial on n-Tier development... anyone know of a good one as it relates
to DESKTOP based applications. Unfortunately, this app I'm working on is
not a web based app.

Thanks
Steve


Jan 31 '06 #24

This discussion thread is closed

Replies have been disabled for this discussion.