Reasons for a 3-tier achitecture for Web? Why

Reasons for a 3-tier achitecture for the WEB?
(NOTE: I said, WEB, NOT WINDOWS.

DON'T shoot your mouth off if you don't understand the difference.)

I hear only one reason and that's to switch a database from SQL Server to
Oracle or DB2 or vice versa... and that's it.... And a lot of these
enterprises don't need it as they already know what database they are going
to use and they don't plan on switching in and out database in the first
place, NOR can they afford to in the first place

Nobody switches databases everyday yet Microsoft and MVP's are recommending
these so called best practices for every single .NET implementation for the
enterprise or the mom and pop....Sort of like Windows Advanced Server and
Windows Server....everybody's got to have Advanced server on their
LAPTOP.....

I mean come on. Let Microsoft fix their own stuff FIRST before recommending
any best practices.

Also see no reason to have a business logic tier as that can be easily
contained in the code behind.

QUESTION OF THE DAY:
I would really like to know, who's idea it was to have 3-tier architecture
for .NET Web Pages. All I see is a carry over of practices from DNA using
COM and .asp pages.....

3-tier is using the same OLD broken tools when a new technology, .NET, that
has better and more simplier ways of doing things.

I say there is some hidden motive (like job security) for making things more
complicated and LESS performing when using 3-Tier or N-Tier.

There are a LOT of mind-numb robot MVP's and Microsoft employees who never
question if a particular and well-entrenched way is the best way.......

It's been 2 years and Mr. Bill is still saying things are going slow.....I
wonder why......

re: Reasons for a 3-tier achitecture for Web? Why

Hi,

Multi-tier architectures proved to be reasonable for considerably big
projects where they facilitate maintenance and further development (have you
ever tried to debug a huge code-behind class with thousands of lines of
code?).

It is just easier (well, for some of us, at least :-) to work with logically
separated parts of code - this one works with the database, this one handles
business rules and that one renders user interface.

By the way, the "business logic" tier, in my opinion, is reasonable only
when there are many complex business rules to enforce. This tier can be
omitted for web sites that merely store and display data, but do not perform
any sophisticated data processing.

As for switching the databases...well..I would agree that it happens with
very low probability, but if that happens and all your database code is
spread across the code behind - long boring hours of monkey job are
guaranteed.

--
Dmitriy Lapshin [C# / .NET MVP]
X-Unity Unit Testing and Integration Environment
http://x-unity.miik.com.ua
Deliver reliable .NET software

"nospam" <n@ntspam.com> wrote in message
news:#lGPJeXZDHA.1640@TK2MSFTNGP10.phx.gbl...[color=blue]
> Reasons for a 3-tier achitecture for the WEB?
> (NOTE: I said, WEB, NOT WINDOWS.
>
> DON'T shoot your mouth off if you don't understand the difference.)
>
> I hear only one reason and that's to switch a database from SQL Server to
> Oracle or DB2 or vice versa... and that's it.... And a lot of these
> enterprises don't need it as they already know what database they are[/color]
going[color=blue]
> to use and they don't plan on switching in and out database in the first
> place, NOR can they afford to in the first place
>
> Nobody switches databases everyday yet Microsoft and MVP's are[/color]
recommending[color=blue]
> these so called best practices for every single .NET implementation for[/color]
the[color=blue]
> enterprise or the mom and pop....Sort of like Windows Advanced Server and
> Windows Server....everybody's got to have Advanced server on their
> LAPTOP.....
>
> I mean come on. Let Microsoft fix their own stuff FIRST before[/color]
recommending[color=blue]
> any best practices.
>
> Also see no reason to have a business logic tier as that can be easily
> contained in the code behind.
>
> QUESTION OF THE DAY:
> I would really like to know, who's idea it was to have 3-tier architecture
> for .NET Web Pages. All I see is a carry over of practices from DNA using
> COM and .asp pages.....
>
> 3-tier is using the same OLD broken tools when a new technology, .NET,[/color]
that[color=blue]
> has better and more simplier ways of doing things.
>
> I say there is some hidden motive (like job security) for making things[/color]
more[color=blue]
> complicated and LESS performing when using 3-Tier or N-Tier.
>
> There are a LOT of mind-numb robot MVP's and Microsoft employees who never
> question if a particular and well-entrenched way is the best way.......
>
> It's been 2 years and Mr. Bill is still saying things are going slow.....I
> wonder why......
>
>
>
>
>
>[/color]

re: Reasons for a 3-tier achitecture for Web? Why

Also, there's one thing that you're missing - the service
oriented architecture. If you place code in the code
behind page, it can't be called from another process
without loading up the entire web page, transferring to
that site, etc. Using middle tier logic enables you to
hold common services for use across many applications.
It's not just all based on database issues.

Jeff Levinson

Author of "Building Client/Server Applications with
VB.NET: An Example Driven Approach"
[color=blue]
>-----Original Message-----
>Reasons for a 3-tier achitecture for the WEB?
>(NOTE: I said, WEB, NOT WINDOWS.
>
>DON'T shoot your mouth off if you don't understand the[/color]
difference.)[color=blue]
>
>I hear only one reason and that's to switch a database[/color]
from SQL Server to[color=blue]
>Oracle or DB2 or vice versa... and that's it.... And a[/color]
lot of these[color=blue]
>enterprises don't need it as they already know what[/color]
database they are going[color=blue]
>to use and they don't plan on switching in and out[/color]
database in the first[color=blue]
>place, NOR can they afford to in the first place
>
>Nobody switches databases everyday yet Microsoft and[/color]
MVP's are recommending[color=blue]
>these so called best practices for every single .NET[/color]
implementation for the[color=blue]
>enterprise or the mom and pop....Sort of like Windows[/color]
Advanced Server and[color=blue]
>Windows Server....everybody's got to have Advanced[/color]
server on their[color=blue]
>LAPTOP.....
>
>I mean come on. Let Microsoft fix their own stuff FIRST[/color]
before recommending[color=blue]
>any best practices.
>
>Also see no reason to have a business logic tier as that[/color]
can be easily[color=blue]
>contained in the code behind.
>
>QUESTION OF THE DAY:
>I would really like to know, who's idea it was to have 3-[/color]
tier architecture[color=blue]
>for .NET Web Pages. All I see is a carry over of[/color]
practices from DNA using[color=blue]
>COM and .asp pages.....
>
>3-tier is using the same OLD broken tools when a new[/color]
technology, .NET, that[color=blue]
>has better and more simplier ways of doing things.
>
>I say there is some hidden motive (like job security)[/color]
for making things more[color=blue]
>complicated and LESS performing when using 3-Tier or N-[/color]
Tier.[color=blue]
>
>There are a LOT of mind-numb robot MVP's and Microsoft[/color]
employees who never[color=blue]
>question if a particular and well-entrenched way is the[/color]
best way.......[color=blue]
>
>It's been 2 years and Mr. Bill is still saying things[/color]
are going slow.....I[color=blue]
>wonder why......
>
>
>
>
>
>
>.
>[/color]

re: Reasons for a 3-tier achitecture for Web? Why

Just how many lines of code in a Code Behind Page are too much?

I have seen thousands and thousands of lines of code in a business tier as
well, I see no difference.

I would also like to know the actual business SET of rules where this would
happen for each and every single web page.

I can think of only a few cases(i.e. web pages) where this might be,

(1.) Placing an order for like a shopping cart
(2.) Credit approval
(3.) Insurance approval

But that's it.
I see no reason to put the (1) login or (2) search (3)Order Details or the
rest of the web site all in a business tier.

People talk about these "so-called" business rules as if it's in every
single page of the web site. yet that's not true and only increases the
complexity of the web site.
[color=blue]
> It is just easier (well, for some of us, at least :-) to work with[/color]
logically[color=blue]
> separated parts of code - this one works with the database, this one[/color]
handles[color=blue]
> business rules and that one renders user interface.[/color]

Can you explain, "just why is it easier"? Like is there some feature I am
missing? I coded more pages and sites than any of the top coders I know,
database, business logic and all and possibly more than all of them put
together.

What about all the time you spend trying to figure out grey area rules?
Like is this really in this layer or that layer, or is it really a little
bit of both. And then trying to Later figure out where it is 2 months from
now.



"Dmitriy Lapshin [C# / .NET MVP]" <x-code@no-spam-please.hotpop.com> wrote
in message news:ecSn6nXZDHA.2960@tk2msftngp13.phx.gbl...[color=blue]
> Hi,
>
> Multi-tier architectures proved to be reasonable for considerably big
> projects where they facilitate maintenance and further development (have[/color]
you[color=blue]
> ever tried to debug a huge code-behind class with thousands of lines of
> code?).
>
> It is just easier (well, for some of us, at least :-) to work with[/color]
logically[color=blue]
> separated parts of code - this one works with the database, this one[/color]
handles[color=blue]
> business rules and that one renders user interface.
>
> By the way, the "business logic" tier, in my opinion, is reasonable only
> when there are many complex business rules to enforce. This tier can be
> omitted for web sites that merely store and display data, but do not[/color]
perform[color=blue]
> any sophisticated data processing.
>
> As for switching the databases...well..I would agree that it happens with
> very low probability, but if that happens and all your database code is
> spread across the code behind - long boring hours of monkey job are
> guaranteed.
>
> --
> Dmitriy Lapshin [C# / .NET MVP]
> X-Unity Unit Testing and Integration Environment
> http://x-unity.miik.com.ua
> Deliver reliable .NET software
>
> "nospam" <n@ntspam.com> wrote in message
> news:#lGPJeXZDHA.1640@TK2MSFTNGP10.phx.gbl...[color=green]
> > Reasons for a 3-tier achitecture for the WEB?
> > (NOTE: I said, WEB, NOT WINDOWS.
> >
> > DON'T shoot your mouth off if you don't understand the difference.)
> >
> > I hear only one reason and that's to switch a database from SQL Server[/color][/color]
to[color=blue][color=green]
> > Oracle or DB2 or vice versa... and that's it.... And a lot of these
> > enterprises don't need it as they already know what database they are[/color]
> going[color=green]
> > to use and they don't plan on switching in and out database in the first
> > place, NOR can they afford to in the first place
> >
> > Nobody switches databases everyday yet Microsoft and MVP's are[/color]
> recommending[color=green]
> > these so called best practices for every single .NET implementation for[/color]
> the[color=green]
> > enterprise or the mom and pop....Sort of like Windows Advanced Server[/color][/color]
and[color=blue][color=green]
> > Windows Server....everybody's got to have Advanced server on their
> > LAPTOP.....
> >
> > I mean come on. Let Microsoft fix their own stuff FIRST before[/color]
> recommending[color=green]
> > any best practices.
> >
> > Also see no reason to have a business logic tier as that can be easily
> > contained in the code behind.
> >
> > QUESTION OF THE DAY:
> > I would really like to know, who's idea it was to have 3-tier[/color][/color]
architecture[color=blue][color=green]
> > for .NET Web Pages. All I see is a carry over of practices from DNA[/color][/color]
using[color=blue][color=green]
> > COM and .asp pages.....
> >
> > 3-tier is using the same OLD broken tools when a new technology, .NET,[/color]
> that[color=green]
> > has better and more simplier ways of doing things.
> >
> > I say there is some hidden motive (like job security) for making things[/color]
> more[color=green]
> > complicated and LESS performing when using 3-Tier or N-Tier.
> >
> > There are a LOT of mind-numb robot MVP's and Microsoft employees who[/color][/color]
never[color=blue][color=green]
> > question if a particular and well-entrenched way is the best way.......
> >
> > It's been 2 years and Mr. Bill is still saying things are going[/color][/color]
slow.....I[color=blue][color=green]
> > wonder why......
> >
> >
> >
> >
> >
> >[/color]
>[/color]

re: Reasons for a 3-tier achitecture for Web? Why

I can only think of one thing that is maybe common, and that's validation.

Other than that, there is nothing else.

Plus, there is a trade off on encapsulation as well and not to mention
reliabilty and maintenance.

Having code HERE and THERE amounts to "spaghetti" code.

Any custom code that is called more than once is also a single point of
failure and also each and every web page that uses it must be tested for
Quality Assurance. It seems like the time saved in hand coding changes are
easily lost in QA. Then is this myth about the "2 second maintenance
change" that never, ever is really 2 seconds.


"Jeff Levinson [mcsd]" <jefflevinson1@comcast.net> wrote in message
news:033401c365ba$a61c2290$a301280a@phx.gbl...[color=blue]
> Also, there's one thing that you're missing - the service
> oriented architecture. If you place code in the code
> behind page, it can't be called from another process
> without loading up the entire web page, transferring to
> that site, etc. Using middle tier logic enables you to
> hold common services for use across many applications.
> It's not just all based on database issues.
>
> Jeff Levinson
>
> Author of "Building Client/Server Applications with
> VB.NET: An Example Driven Approach"
>[color=green]
> >-----Original Message-----
> >Reasons for a 3-tier achitecture for the WEB?
> >(NOTE: I said, WEB, NOT WINDOWS.
> >
> >DON'T shoot your mouth off if you don't understand the[/color]
> difference.)[color=green]
> >
> >I hear only one reason and that's to switch a database[/color]
> from SQL Server to[color=green]
> >Oracle or DB2 or vice versa... and that's it.... And a[/color]
> lot of these[color=green]
> >enterprises don't need it as they already know what[/color]
> database they are going[color=green]
> >to use and they don't plan on switching in and out[/color]
> database in the first[color=green]
> >place, NOR can they afford to in the first place
> >
> >Nobody switches databases everyday yet Microsoft and[/color]
> MVP's are recommending[color=green]
> >these so called best practices for every single .NET[/color]
> implementation for the[color=green]
> >enterprise or the mom and pop....Sort of like Windows[/color]
> Advanced Server and[color=green]
> >Windows Server....everybody's got to have Advanced[/color]
> server on their[color=green]
> >LAPTOP.....
> >
> >I mean come on. Let Microsoft fix their own stuff FIRST[/color]
> before recommending[color=green]
> >any best practices.
> >
> >Also see no reason to have a business logic tier as that[/color]
> can be easily[color=green]
> >contained in the code behind.
> >
> >QUESTION OF THE DAY:
> >I would really like to know, who's idea it was to have 3-[/color]
> tier architecture[color=green]
> >for .NET Web Pages. All I see is a carry over of[/color]
> practices from DNA using[color=green]
> >COM and .asp pages.....
> >
> >3-tier is using the same OLD broken tools when a new[/color]
> technology, .NET, that[color=green]
> >has better and more simplier ways of doing things.
> >
> >I say there is some hidden motive (like job security)[/color]
> for making things more[color=green]
> >complicated and LESS performing when using 3-Tier or N-[/color]
> Tier.[color=green]
> >
> >There are a LOT of mind-numb robot MVP's and Microsoft[/color]
> employees who never[color=green]
> >question if a particular and well-entrenched way is the[/color]
> best way.......[color=green]
> >
> >It's been 2 years and Mr. Bill is still saying things[/color]
> are going slow.....I[color=green]
> >wonder why......
> >
> >
> >
> >
> >
> >
> >.
> >[/color][/color]

re: Reasons for a 3-tier achitecture for Web? Why

"nospam" <n@ntspam.com> wrote in message
news:#lGPJeXZDHA.1640@TK2MSFTNGP10.phx.gbl...[color=blue]
> Reasons for a 3-tier achitecture for the WEB?
> (NOTE: I said, WEB, NOT WINDOWS.
>
> DON'T shoot your mouth off if you don't understand the difference.)
>
> I hear only one reason and that's to switch a database from SQL Server to
> Oracle or DB2 or vice versa... and that's it.... And a lot of these
> enterprises don't need it as they already know what database they are[/color]
going[color=blue]
> to use and they don't plan on switching in and out database in the first
> place, NOR can they afford to in the first place
>
> Nobody switches databases everyday yet Microsoft and MVP's are[/color]
recommending[color=blue]
> these so called best practices for every single .NET implementation for[/color]
the[color=blue]
> enterprise or the mom and pop....Sort of like Windows Advanced Server and
> Windows Server....everybody's got to have Advanced server on their
> LAPTOP.....
>[/color]

If you had sold a product to companies, you'll easily find out that the
database implementation is not always as you had planned. The same product
can be be deployed in different companies using different RDBMS products
(well, if you don't want to, you've just limited yourself to a few clients).
Not to mention those "Mom and Pop" shops that can only afford access, and
later on outgrow the system and would demand a robust RDBMS. Well, that's
one reason. In some cases (specially tracing and logging), the persistent
store is not always a database. It can be a flat file, your email service
or logging objects in windows. Wouldn't you rather write a design where you
can just "switch" your application to use any of these objects that logs
information differently. I know you're thinking, why in the world would you
choose to log information in a flat file when you have a database or
whatever. Depending on who you are... in today's distributed
envinronments, technical support can be in far flung India while the program
is running in Iraq. Are you going to send the entire database image to them
so they can analyze a problem that occurred in the last 5 minutes? I can
think of so many reasons why you should separate your "Data Layer" from the
other "Layers."
[color=blue]
> I mean come on. Let Microsoft fix their own stuff FIRST before[/color]
recommending[color=blue]
> any best practices.
>[/color]

I agree on this one but this does not have any bearing on your question of
"3 Tier Architecture."
[color=blue]
> Also see no reason to have a business logic tier as that can be easily
> contained in the code behind.
>[/color]

Again, imagine an application where you have to write an interface for PDA's
and full browser like I.E. Coding the business rules for pages that supply
information in a PDA and another for I.E. is just too much to do. I don't
know about you, but I would rather spend more time upgrading my system than
doing interfaces (with built in business rules) so many times, depending on
how many client interfaces I have to deal with. Just consider if you have
to write a "Touch Tone" interface to your application as well.
[color=blue]
> QUESTION OF THE DAY:
> I would really like to know, who's idea it was to have 3-tier architecture
> for .NET Web Pages. All I see is a carry over of practices from DNA using
> COM and .asp pages.....
>[/color]

This idea was definitely not from Microsoft. But the idea behind n-tier
architecture is code reuse. Unless, you haven't heard of it.
[color=blue]
> 3-tier is using the same OLD broken tools when a new technology, .NET,[/color]
that[color=blue]
> has better and more simplier ways of doing things.
>[/color]

N-Tier development is an architectural design that allows a development team
to work together by establishing standards before the first code is ever
written. That way, you can avoid the saying, "Too many chefs spoils the
broth."
[color=blue]
> I say there is some hidden motive (like job security) for making things[/color]
more[color=blue]
> complicated and LESS performing when using 3-Tier or N-Tier.
>[/color]

Even in non n-tier designs, Job security has always been a motive. It isn't
even hidden anymore. Don't you think so? I wonder why so many people are
still in denial that job security is a goal.
[color=blue]
> There are a LOT of mind-numb robot MVP's and Microsoft employees who never
> question if a particular and well-entrenched way is the best way.......
>[/color]

That's because it's a proven "practice." I don't even call it a design
anymore. Code behind leads to too much duplicate code all over the
application. But since you prefer to do things the long way... good luck
investing more time in writing a simple "logon" screen. By the way, the
tools that you get out there to write "components" are based on the very
n-tier design that you don't agree with. Have you noticed that they work
with almost every DB out there? I wonder why?
[color=blue]
> It's been 2 years and Mr. Bill is still saying things are going slow.....I
> wonder why......
>[/color]

You know, there are other tools out there you can use, some are even free...
but, they too have been centered on n-tier development. I suggest you try
J2EE. You'll see the real power of n-Tier design. It's even amazing how
they've put away with proprietary SQL code.
[color=blue]
>
>
>
>
>[/color]

re: Reasons for a 3-tier achitecture for Web? Why

comments inline below


"nhoel" <noemail@nomail.com> wrote in message
news:%23JTfGhdZDHA.2632@TK2MSFTNGP09.phx.gbl...[color=blue]
> If you had sold a product to companies, you'll easily find out that the
> database implementation is not always as you had planned. The same[/color]
product[color=blue]
> can be be deployed in different companies using different RDBMS products
> (well, if you don't want to, you've just limited yourself to a few[/color]
clients).[color=blue]
> Not to mention those "Mom and Pop" shops that can only afford access, and
> later on outgrow the system and would demand a robust RDBMS. Well, that's
> one reason. In some cases (specially tracing and logging), the persistent
> store is not always a database. It can be a flat file, your email service
> or logging objects in windows. Wouldn't you rather write a design where[/color]
you[color=blue]
> can just "switch" your application to use any of these objects that logs
> information differently. I know you're thinking, why in the world would[/color]
you[color=blue]
> choose to log information in a flat file when you have a database or
> whatever. Depending on who you are... in today's distributed
> envinronments, technical support can be in far flung India while the[/color]
program[color=blue]
> is running in Iraq. Are you going to send the entire database image to[/color]
them[color=blue]
> so they can analyze a problem that occurred in the last 5 minutes? I can
> think of so many reasons why you should separate your "Data Layer" from[/color]
the[color=blue]
> other "Layers."[/color]

still weak arguments....FLAT FILE...come ON? TO INDIA? EXCUSE me...that's
NO reason.
Backup the database and zip it up and send it over there...what's the
difference?
These points are simply Weird and don't occur in real life.
Mom and Pop on access....just have them install MSDE then?....the amount of
effort to SWITCH is total NONSENSE as you could have just had them switch to
MSDE.......They, the client are happy and so are you.
Getting a Mom and Pop to buy your enterprise app is simply improbable as
they can't afford it....YET, if they could afford it, why would they use
access?



[color=blue]
>[color=green]
> > I mean come on. Let Microsoft fix their own stuff FIRST before[/color]
> recommending[color=green]
> > any best practices.
> >[/color]
>
> I agree on this one but this does not have any bearing on your question of
> "3 Tier Architecture."
>[color=green]
> > Also see no reason to have a business logic tier as that can be easily
> > contained in the code behind.
> >[/color]
>
> Again, imagine an application where you have to write an interface for[/color]
PDA's[color=blue]
> and full browser like I.E. Coding the business rules for pages that[/color]
supply[color=blue]
> information in a PDA and another for I.E. is just too much to do. I don't
> know about you, but I would rather spend more time upgrading my system[/color]
than[color=blue]
> doing interfaces (with built in business rules) so many times, depending[/color]
on[color=blue]
> how many client interfaces I have to deal with. Just consider if you have
> to write a "Touch Tone" interface to your application as well.[/color]


I would like to know if anyone BUYS stuff off of a PDA like they do a Web
Site shopping cart.
Can you really shop around and surf with a PDA....just look at how small the
screen is....people have enough trouble with 640x-480 now, I can't imagine
what it would be like for a PDA.

Just any device can display information doesn't mean it's going to have or
need a set of complex business rules in the first place. ANYTHING that
complex, you got to ask yourself if the customer is going to really buy
something OR spend time filling out a form on a PDA...YIKES!

Second, it complete poor design practice to have the same set of business
rules as that would be a single point of failure anyway...and the PDA
business requirements are going to be TOTALLY different then a Web Site's


[color=blue][color=green]
> > QUESTION OF THE DAY:
> > I would really like to know, who's idea it was to have 3-tier[/color][/color]
architecture[color=blue][color=green]
> > for .NET Web Pages. All I see is a carry over of practices from DNA[/color][/color]
using[color=blue][color=green]
> > COM and .asp pages.....
> >[/color][/color]
[color=blue]
> This idea was definitely not from Microsoft. But the idea behind n-tier
> architecture is code reuse. Unless, you haven't heard of it.[/color]

OK, well who was it from then if not Microsoft?


[color=blue][color=green]
> > 3-tier is using the same OLD broken tools when a new technology, .NET,[/color]
> that[color=green]
> > has better and more simplier ways of doing things.
> >[/color]
>
> N-Tier development is an architectural design that allows a development[/color]
team[color=blue]
> to work together by establishing standards before the first code is ever
> written. That way, you can avoid the saying, "Too many chefs spoils the
> broth."[/color]

2-Tier can easily do this....Internet and Intranet web sites have hundreds
of web pages where each set of web pages belong to a departments.
With N-Tier, you could like say have one module, but it needs to worked on
two different divisions. Say if it's the database module....what happens if
two people need access to the same time?


[color=blue]
>[color=green]
> > I say there is some hidden motive (like job security) for making things[/color]
> more[color=green]
> > complicated and LESS performing when using 3-Tier or N-Tier.
> >[/color]
>
> Even in non n-tier designs, Job security has always been a motive. It[/color]
isn't[color=blue]
> even hidden anymore. Don't you think so? I wonder why so many people are
> still in denial that job security is a goal.
>[color=green]
> > There are a LOT of mind-numb robot MVP's and Microsoft employees who[/color][/color]
never[color=blue][color=green]
> > question if a particular and well-entrenched way is the best way.......
> >[/color]
>
> That's because it's a proven "practice." I don't even call it a design
> anymore. Code behind leads to too much duplicate code all over the
> application. But since you prefer to do things the long way... good luck
> investing more time in writing a simple "logon" screen. By the way, the
> tools that you get out there to write "components" are based on the very
> n-tier design that you don't agree with. Have you noticed that they work
> with almost every DB out there? I wonder why?
>[/color]

The only thing I see proven are the number of failed enterprise projects
like CRM and ERP.

CRM especially as they are always in the news getting sued for a failed
implementation.

ERP...well that takes at least a year of dev, and by that time, the
technology has changed.

IF YOU notice, the POST said WEB, NOT WINDOWS.....Looking at the TOOLS, like
VS.NET are Windows apps that have a really long beta test and are updated
once a year....big difference here.


[color=blue][color=green]
> > It's been 2 years and Mr. Bill is still saying things are going[/color][/color]
slow.....I[color=blue][color=green]
> > wonder why......
> >[/color]
>
> You know, there are other tools out there you can use, some are even[/color]
free...[color=blue]
> but, they too have been centered on n-tier development. I suggest you try
> J2EE. You'll see the real power of n-Tier design. It's even amazing how
> they've put away with proprietary SQL code.
>[/color]

J2EE!!!! Aghhhh....have you looked at their code.....abstraction after
abstraction after abstraction.....YES, you are right, that's N-TIER...where
the "N" stands for "Not enough" Tiers....It's no wonder why J2EE is so slow
and take forever to implement.

re: Reasons for a 3-tier achitecture for Web? Why

Inline...

"nospam" <n@ntspam.com> wrote in message
news:O4qY0ScZDHA.1872@TK2MSFTNGP12.phx.gbl...[color=blue]
> I can only think of one thing that is maybe common, and that's validation.
>
> Other than that, there is nothing else.[/color]

There are plenty of services that can be shared beyond simple validation.
[color=blue]
> Plus, there is a trade off on encapsulation as well and not to mention
> reliabilty and maintenance.[/color]

You are just arguing in favour of keeping business logic in a separate tier
from the UI logic.
[color=blue]
> Having code HERE and THERE amounts to "spaghetti" code.[/color]

Ditto.
[color=blue]
> Any custom code that is called more than once is also a single point of
> failure and also each and every web page that uses it must be tested for
> Quality Assurance. It seems like the time saved in hand coding changes[/color]
are[color=blue]
> easily lost in QA. Then is this myth about the "2 second maintenance
> change" that never, ever is really 2 seconds.[/color]

You've completely lost me here. How would you code an application so that
every single web page _didn't_ need to be tested individually? With your
"single point of failure" couldn't you stop testing when it did fail, and
then fix it before you go and test it again from a different page knowing
that it's just going to fail again?

Here's a real example of why encapsulating business logic in a single
location is a good thing. I worked on a site that had to validate addresses.
Some genius decided that the only valid postal codes were the one's that had
5 digits. Brilliant decision for an international site. When I got to
changing the business logic to allow international postal codes I discovered
(over a period of about 2 weeks tracking down all the places that a postal
code was entered or used) that the team of consultants had put the
validation logic in the database, in the data access layer, in the business
logic layer, in the UI code and in client-side code. I should note that the
address wasn't being validated multiple times because they only used one of
those layers to do the validation depending on where the address was being
entered. Not only was the logic in 5 different locations, they used
different rules (i.e. some allowed anything and long as it wasn't blank,
some numeric only, some specific alpha-numeric patterns and sometimes it
only required it for US addresses).

You say I have a single point of failure, I say you have multiple places to
completely stuff things up.

Maybe you should come back to this discussion after you've got a bit of
experience developing and maintaining a non-trivial web application.

Colin