Layers or Tiers 在谈论构架和分层的时候，这两个词你应该用哪一个

xblues

http://it.toolbox.com/blogs/high-thinking/layers-or-tiers-11718


Layers or Tiers                        pranshujain (Principal Consultant) posted 9/15/2006 | Comments (1)       
Software architects are a confused lot. Communicating with each otheris a challenge. There is always a discussion about what goes in whatlayer ( or tier) and logical vs Physical separation. Even thedefinition of Data Tier specially is open to interpretation. Here aremy views on UI, App, Data access and Data layers.

Arnonis the first person I saw insisting on calling (potential) physicalseparation as Tier and (Definitely) logical separation as layer - and Ibelieve its a good separation to have in our vocabulary.

So aLayer becomes a Tier if it could be physically separated from thelayers consuming it. Or a Tier is a Layer which could be physicallyseparated from the layers consuming it. Now coming to a typical3-Tierarchitecture. Here we talk about a UI "Layer", Business Logic"Layer" and Data "Layer".

We all agree that a UI layer takescare of presentation. Typical UI frameworks will also encourage you todo validations at this layer, presentation specific logic at this layer( like selectively showing or hiding fields) and use the events andData at the UI to invoke the appropriate business logic.

Allthis is fine, except for one confusion created by J2EE app servers. TheJava App servers initial documentation tell you that manage the staticfiles, images on the web servers and manage the JSP pages on the Appserver.
I would say that while creating a 3-tier application, ignorethe existence of the web servers. The UI layer, Presentation layerwhatever you want to call it is a part of a J2EE app server, or is apart of ASP.NET worker process and not a part of "pure" web server. Ifby any chance or coincidence it happens that the web servers containother files apart from the plugin to the ASP/JSP runtime, just treat itoutside of the presentation layer. If you feel these files areimportant, bring them in into your application distributable ratherthan keeping them outside.

Next is the Business Logic Layer orthe App Layer. The app layer contains all the business logic. This isthe only interface that the web layer, UI layer or Presentation layercalls. The conventional application architecture defines that thepresentation layer and business logic layer should be kept on separatephysical machines. Hence they should be "Tiers". Why?

- Securityengineers want to place one more firewall to create a "DMZ". For somereason known only to them, they say that two firewalls are more securethan one - and that sounds perfectly reasonable to me. So they say thatAll external connectivity requirements - including those to othersystems in the same or a different datacenter must be behind the secondfirewall, which is either on the app tier or below. Just repeating whatI said above - the App tier is the only interface that the web tiercalls.

- Scaling: Web applications tend to be stateful, managinguser sessions. The app tier tends to be stateless. Its not possible todistribute load evenly to statefull tiers - as you dont know if onesession is heavier than the other session. However, by having a verysmall number of web servers and putting the bulk of processing on appservers which can have better load distribution, we get more optimalscaling.

So - It is good idea to have a web/ui/presentation layer as a tier.

Nowlets come to Data Layer. This is where the architects around the worlduniversally confuse each other. Some say the Data layer is the databaseor the file system ( i.e. Raw Data), some say that Data layer is theCRUD Data objects exposed to the app layer for editing, some say thatData layer is till the object end of my O-R mapping tool and some saythat the Data layer is the Objects which know how to persist themselves- like entity beans.
Now this is here the distinction between A Tier and a Layer is most useful.

Ina typical Architecture, We will have a DATA TIER. The data tier is thedatabase, file system, search engine index - or the Amazon's web datastorage service - whatever.

Then we have a Data Access Layer -which is a piece of code which helps the business logic Layer interactwith the persistent data in the Data Tier. This Data access layer couldbe DAO objects, Entity beans, OR mapped objects or a layer of objectsexposing CRUD functionality.

Typically the Data Access Layer is not a TIER, it is kept along with the business logic layer in the App Tier.
Thereare however a few exceptions - as their always will be. If your datastore is not thread safe (yes its entirely possible) - then you mightneed to put a "locking" layer over it which allows only one person towrite on it at a time. This piece of code becomes a part of data tier.It is entirely possible that in your design, your business layerdirectly interacts with this data tier object without going thruanother data access layer in between, Or to put it in other words, fora non thread safe data store, the data layer - should be made a Tier.

Now there are two questions left to be answered
1) From a developer's perspective whats the difference between a layer and a tier?
2) What about stored procedures ?

Layer and Tier:
Thelayers reside on the same machine, same runtime ( JVM or CLR) and anyobject visible to one layer can be passed to the other either by Valueor by Reference. However the tiers could be on different machines or ondifferent runtimes, hence the data has to passed by Value only - asserialized objects. The other difference is a lookup - you need toallow UI Tier code to look up and call remote App tier methods. .NETremoting, web services, RMI, remote invocation of EJB's all provideinfrastructure for doing the same

Stored Procedure:
This is areally really murky discussion. I am sure most will not agree with whatI say, but I will say anyway. The way I view it, when you call a storedprocedure, you expect a data back, so it is a part of the Data tier.Fetching that data may require some processing. But the very reason whythe logic is implemented in stored procedure is that the logic is dataintensive, so it doesnot strike me as "unclean". I have seen manyimplementations where SP are used for different very logical reasons.

1)stored procedures use very simple interfaces to expose a complexunderlying data. This is almost like OR mapping ( like lets say youhave a User object, which maps to 3 tables, user, userpreferences anduserAddress, it will have crud methods exposed at User level by thestored procedure)
2) Containing frequently changing logic: changingstored procedure is easier than application installation. Some peoplekeep such frequently changing logic as a stored procedure. This isdefinitely not business tier. This is what makes the separation murky.I think a rules engine is a better place to store the same.
3)Making App layer independant of data changes: Sometime the data storeis used by more than one application. Any of the applications using itmay impose a change on the schema. By having stored procedures for allconsumers, it makes maintainability easier as the party changing thedatabase can easily ensure that all stored procedures in the databasecontinue to work as they were before the schema change.
As abottomline here we can say that all rules could be broken for a goodreason. So If you think your idea is clever - go with it.

Now coming to physical architecture:
a typical way to keep the tiers in a web application is
<Firewall>Web Tier <Firewall> App Tier (Business logic + Data accesslayers) <> Data Tier (Database/file system).
It is entirelypossible to load all tiers into the same machine, but it is importantto take care of not being dependant on references when going acrosstiers.

                               
登录/注册后可看大图

       
                Previous Entry /  Next Entry
       
Vendors Mentioned

xblues

好象是没区别的啊， application tier           application layer

coredump

physical separation as Tier and (Definitely) logical separation as layer

貌似的确是这样

xblues

你确定么？ 问问你同事。

kaisy

I agree with #3 coredump .
Please refer to the following :

So far, this guide has described the application architecture in terms of logical layers. It is important to remember that these layers are simply a convenient way to describe the different kinds of functionality in the application.


How you deploy your physical application layers into tiers is driven by how the layers interact with each other and the different requirements they have in terms of security, operations, and communication.

which comes from:
http://msdn.microsoft.com/en-us/library/ms978363.aspx

[ 本帖最后由 kaisy 于 25-12-2008 22:16 编辑 ]

yuba

原来是这么回事儿啊

我一直用 floor