三层与 n 层之间的差异
我刚刚看到下面这句话：
随着行业从三 从层模型到n层模型，对象关系阻抗不匹配变得更加普遍。
但我找不到三层和n层之间区别的简明解释。 我知道三层是什么，我假设 n 层只是添加一层或多层。 我只是不确定这些额外的层是什么。 如果有人有一个简短的解释或只是一个好的链接，我们将不胜感激。
I just came across the following sentence:
As the industry has moved from a three
tier model to n-tier models, the object relational impedance mismatch has become more prevalent.
But I can't find a concise explanation of the difference between three tier and n-tier. I know what three tier is, and I assume n-tier just adds one or more tiers. I'm just not sure what these additional tiers would be. If anyone has a short explanation or simply a good link, that would be much appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
在开发中，我们将层理解为“责任级别”抽象。
这种级别的责任将概念组合在一起，以提供现实的连贯语义视图，或者至少是类似于现实的东西。
从这个意义上说，所谓的三层模型或n层模型只是该概念的不同实现。
层级的一个很好的例子是遵循粗俗的模型，其中的责任被仔细地分配给适当的人。 例如，一个常见的企业有商业、营销、系统、开发和测试部门（例如），它们代表业务层级。 这样，职责就很明确，开发提供产品，测试测试它，营销推广它，商业销售它，所有这些都在系统保持基础设施运行的同时（只是一个例子）。
这个比喻首先是通过 3 层模型来实现的，其中确定了三个层。 通常这一层是数据库抽象层，负责数据库的通信和抽象，业务规则层，它保存描述业务流程和的规则。 >用户界面层抽象用户与系统的交互。
这样，我们就为每一层的职责分配了角色，这样，如果用户需要与系统交互，他将与一层进行通信，而不会弄乱整个系统。
N 层代表了前一个概念的演变，通过使用更多层来满足特定需求。 通常用户界面层和数据库抽象层保持不变，因为它们的角色非常明确，而业务规则层则进一步细化。
为此，我们始终考虑问题的特征以及我们现在和将来想要提供的功能。 例如，如果应用程序需要与智能客户端一起工作或预计与智能客户端一起工作，那么业务层通常分为代理层和后端层，首先将调用路由到它们应该去的地方。
最后，重要的是不同层之间抽象职责的概念，并从语义角度将所有相关操作集中在同一个地方。
此外，请注意，n 层架构允许在开发人员之间分配这些“职责”。 这样，一个给定的团队可以负责数据库抽象层，而其他团队负责代理层，另一个团队负责图形抽象层。 当团队成员需要访问数据库时，他会查找 DAL 文档并使用提供的工具之一，或者要求 DAL 团队提供他需要的功能，这样他就不会直接访问数据库，而是通过更了解数据库本身的设计和复杂性的人员。
In development we understand a tier as a "level of responsibility" abstraction.
Such level of responsibility groups concepts together to provide a coherent semantic view of reality, or at least something similar to reality.
In such sense, the so called, 3-tier model or n-tier models are just different implementations of that concepts.
A good example of a tier follows the jerarquical model where responsibilities are carefully addressed to the appropriate people. For example, a common business has Commercial, Marketing, Systems, Development and Test department (for example), which represent tiers of business. That way, responsibilities are clear, Development provides the product, Testing test it, Marketing promote it and Commercial sell it, all that while systems keep the infrastructure running (is just an example).
This metaphor was first approached with the 3-tier model, where three tiers are identified. Usually this tiers are Database Abstraction Layer, which is in charge of communication and abstraction over the database, Business Rules Layer, which holds the rules that describe the business process and User Interface Layer which abstracts the interaction of the user with the system.
That way, we have roles for the responsibilities of each layer, so that if the user needs to interact with the system he will communicate with one layer, not mess up across the hole system.
N-tier represent an evolution of the former concept by using more tiers to address specific needs. Usually user interface layer and database abstraction layer are left untouched, as their roles are pretty clear while business rules layer is further refined.
For that, we always take into account the characteristics of the problem as well as the features we want to provide now and in the future. For example, if an application will need to work with smart clients or its foreseen to work with smart clients then business layer is usually divided into a proxy layer and a back-end layer, the first routing the calls where they should go.
In the end, what's important is the concept of abstracting responsibilities among different layers, and centralizing all related operations from a semantic view in the same place.
Note that, in addition, n-tier architecture allows for distribution of those "responsibilities" among developers. That way, a given team can have responsibility over the Database Abstraction Layer while other team works on the Proxy Layer and another one works on the Graphics Abstraction Layer. When a member of a team needs to access the database he look up the DAL documentation and use one of the facilities provided or ask the DAL team to provide with the functionality he needs, so that he does not address directly the database but through the people that better known the design and intricacies of the database itself.
如果我们将层视为蛋糕的层；每一层都有自己的成分并做自己的事情。 每个应用程序的层仅与其上方或下方的层交互。
3层是指蛋糕有3层。 通常它是底部的数据，然后是应用程序逻辑层（PHP / ruby /等），然后是顶部的表示层（html）。
拥有n层架构意味着您要设计多层的东西。 您拥有的层数取决于您决定如何制作。
对于大型应用程序或 Web 应用程序来说，这似乎更有意义。
我通常会得到一个 5 层的应用程序。 每一层只能与其上方或下方的一层交互。 这可以为您的应用程序提供出色的可扩展性和标准化。
客户端层
Web 浏览器
表示层
渲染 HTML - Coldfusion/Flash/Ruby/PHP 等。
业务逻辑层
根据需要运行流程和计算 - Coldfusion/Flash/Ruby/PHP 等。
数据集成层
（来自我的开发语言、存储过程等的查询）
数据层
（数据库 - MySQL 等）
If we looked at tiers like being layers of a cake; each layer would have it's own ingredients and do it's own things. The tiers of each application interact with only the tier above it, or below it.
3-tier means the cake has 3 layers. Usually it's data at the bottom, then an application logic tier (PHP/ruby/etc), and then a presentation tier at the top (html)
Having an n-tier architecture means you design something multiple layers layer to it. The number of layers you have will depend on how you decide to make it.
It seems to make a lot more sense with larger, or web applications.
I usually end up with a 5 tier application. Each tier can only interact with the one above it or below it. This can provide fantastic extensibility and standardization across your application.
Client Tier
Web Browser
Presentation Tier
Render the HTML - Coldfusion/Flash/Ruby/PHP,etc.
Business Logic Tier
Run the processes and calculations as needed - Coldfusion/Flash/Ruby/PHP,etc.
Data Integration Tier
(Queries from my Development Language, Stored Procedures, etc.)
Data Tier
(Database - MySQL, etc)
该引用似乎来自此 codeproject 页面。 它似乎也很好地解释了 n 层，包括 Web 服务、javascript、工作流等。所有 3 层模型不一定包括的东西。
The quote appears to be from this codeproject page. It also seems to do a pretty good job of explaining n-tier to include things like web services, javascript, workflows, etc. All things that 3-tier models don't necessarily include.
n 层意味着 n 是任何数字 - 当 n=3 时，它与 n 层相同。
三层的通常定义是表示、逻辑和层次。 是的，SOA 可能会让新手感到困惑，因为有时它位于数据层，有时位于逻辑层，有时位于逻辑层和逻辑层。 数据层。
整个主题是……主观的。 如果您需要一些层，则将其称为 n 层 - 如果您知道 n=7，则将其称为 7 层或 n 层。
n-tier implies n is any number - when n=3 then it is the same as n-tier.
The usual definition of 3-tier is presentation, logic & data (in any order), and yes, SOA can confuse the neophyte because sometimes it sits in the data tier, sometimes the logic tier and sometimes both logic & data tiers.
The whole subject is...subjective. If you need some tiers then call it n-tier - if you know that n=7 then call it 7-tier, or n-tier.
嘿，我什至无法得到 3 层的定义。 有时他们会对客户端上的 javascript 打折，有时客户端上的 javascript 和客户端 Web 浏览器被视为另一层。 因此，如果您假设数据库 = 第 3 层、Web 服务器 = 第 2 层、客户端 Web 浏览器 = 第 1 层，则与数据库对话的 ASP 页面可以是 3 层。而其他时候 Web 服务器 = 第 1 层、中间件 = 第 2 层、数据库 =第三层。这实际上取决于谁在写定义/书。
一般来说，n 层似乎是指将中间件层进一步拆分。 但除此之外，我没有看到一致的定义。
Hey I can't even get a definition of 3 tier. Sometimes they discount javascript on the client and sometimes javascript on the client and the client web browser are considered another tier. So an ASP page that talks to a database can be 3 tier if you assume database = tier 3, web server = tier 2, client web browser = tier 1. And other times web server = tier 1, middleware = tier 2, database = tier 3. It really depends who is writing the definition/book.
In general n-tier seems to refer splitting the middleware layer up more. But aside from that I don't see consistent definitions.
这句话出自哪里？ 他们指的是什么行业？ 我不得不想象这与 SOA 有关，因为这是唯一的对于这种说法来说是有意义的。
我听过的大多数做出这种说法的人都认为，在面向服务的领域中，每个服务在某种程度上都有自己的层。 我不同意，因为大多数时候这些不同的服务可以在逻辑上分为公共的三层（表示、逻辑和数据）。 但同样，这一切都非常主观。
Where is that quote from? What industry are they referring to? I would have to imagine that this has something to do with SOA because that is the only thing that makes sense for this kind of statement.
Most people that I have heard who make this kind of statement believe that in a service-oriented domain each service is somehow its own tier. I disagree as most of the time these disparate services can be logically grouped into the common three tiers anyhow (presentation, logic, and data). But again, its all pretty subjective.
您好，请检查此链接，这样您就可以对此有很好的了解
http:// msdn.microsoft.com/en-us/library/ms973829.aspx
hi pls check this link, so u can get good idea regarding this
http://msdn.microsoft.com/en-us/library/ms973829.aspx
这个关于应用程序架构的维基书籍章节是一个简单的指南层，层，并决定您需要使用什么。
This Wiki-book chapter on application architecture is a straightforward guide to layers, tiers, and deciding what you need to use.
如果没有看到这句话的上下文，我认为它指的是服务和中间件的爆炸式增长。
Without seeing the sentence in context, I assume it is referring to the explosion in services and middleware.