Logical layers, if designed well, can also improve scalability. As you
mention, it's a lot easier to move the business logic logical layer off of
the physical server box and onto its own box in the future when you hire
10,000 new data entry operators.
The 'decrease in the cost of development' is not necessarily true for a
small project. Building out multiple layers requires a lot more planning
and a lot more complex testing plans. Code reuse is always a plus, but also
requires a lot more planning.
I think the major factors to decide whether to go 2-tier, 3-tier, n-tier are
probably: 1) budget and resources, 2) system requirements/complexity, 3)
schedule, 4) number of users.
If you are writing a simple database app for an office of 2 people, with a
budget of $500, 2 workstations and a server, very little business logic
involved and it has to be done in a week, is a 3-tier or n-tier solution
necessary or even feasible? Or would it make more sense to give them a
simple 2-tier solution to suit their needs, and when they hire 100 new
employees and can afford a $50,000 budget you can submit a proposal on a new
3-tier/n-tier solution?
"Rockford Lhotka" <
rocky.spambad@lhotka.net>wrote in message
Quote
There's an important difference between physical tiers and logical tiers
(often called layers).
Physical tiers are a tradeoff between things like performance,
scalability, fault-tolerance, security and so forth.
Logical layers are all about improving maintainability of code, decreasing
cost of development, promoting reuse and so forth.
In general terms, software should be built using an organized set of
logical layers - often Presentation/Business/Data.
Sometimes, typically due to scalability or security requirements those
layers may be deployed to separate physical tiers - thus resulting in an
n-tier system. This invariably increases the cost and complexity of a
system, and so should only be done if the scalability or security benefits
outweigh the costs.
Rocky
--
Rockford Lhotka
Magenic Technologies
rocky at lhotka dot net www.lhotka.net">www.lhotka.net
"Michael C#" <xyz@abcdef.com>wrote in message
news:UuFAe.11084$js.6453@fe10.lga...
>Three tier is more scalable than two tier. In three-tier, or n-tier,
>your middle tiers can take on the responsibility of "traffic cops", cache
>data if you require, and cut down on the number of database connections
>required for hundreds or thousands of users.
>
>"John" <John@nospam.infovis.co.uk>wrote in message
>news:OqIatKohFHA.1416@TK2MSFTNGP09.phx.gbl...
>>How does number of user relate to the tiers of the app?
>>
>>Thanks
>>
>>Regards
>>
>>"Michael C#" <xyz@abcdef.com>wrote in message
>>news:fSEAe.165791$t07.127957@fe12.lga...
>>>A well-developed three-tier is better, but it might be overkill. It
>>>depends on a lot of factors like how many people are going to be using
>>>the system simultaneously? Number and complexity of business rules?
>>>Network bandwidth (thin client/fat client)? How much data is being
>>>stored? Etc.
>>>
>>>For a simple, basic app that only one or two people at a time will use,
>>>two-tier would probably be sufficient; especially if you're on a tight
>>>deadline. For a scalable app that has more complex busines logic and
>>>needs to handle many simultaneous users, three-tier/n-tier is the way
>>>to go.
>>>
>>>"John" <John@nospam.infovis.co.uk>wrote in message
>>>news:uaDJp2mhFHA.1164@TK2MSFTNGP10.phx.gbl...
>>>>Hi
>>>>
>>>>I am making a simple contacts app involving clients, suppliers etc.
>>>>Mostly it involves data entered by the user being saved in the db and
>>>>then user able to search/browse the data. My question is; is it still
>>>>advantageous to bind ui elements to clients, suppliers "business"
>>>>objects which in turn deal with the db or can I bind ui elements
>>>>directly to db? In other words is it useful to have a three-tier app
>>>>instead of a two-tier one even in this simple case? Reasons?
>>>>
>>>>Thanks
>>>>
>>>>Regards
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
-
