n 层对您意味着什么？
多年来我注意到，不同的开发人员对于 n 层系统开发中的层的构成有不同的标准，因此我很好奇 stackoverflow 上的共识是什么。
单独的逻辑层是否足以将其称为单独的层，或者是否必须将其部署在单独的服务器（物理或虚拟）上才能将其称为单独的层？
让我稍微不同地表述这个问题。 如果调用机制只能在进程、线程本地或单元本地，那么是否可以根据类如何组织到库或包中来声明它是两个不同的层？
I have noticed over the years that different developers have different criteria for what constitutes a tier in the development of an n-tier system so I was curious about what the consensus is here at stackoverflow.
Is separate logical layers sufficient to call it a separate tier or does it have to be deployable on a separate server (physical or virtual) in order to call it a separate tier?
Let me phrase the question a little bit differently. If the calling mechanism can only be in process, thread local, or apartment local, then is it possible to claim that it is two different tiers depending on how the classes are organized into libraries or packages?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
一个单独的逻辑层足以让我将其称为层。 它不一定必须位于单独的服务器上，但与其他层的定义分离无疑使其成为可能。
作为一个例子，我们曾经在一台服务器上运行我所说的三层系统（db、dll、asp 页面）。 根据某些定义，这是一个单层系统。 我们现在让数据库在单独的服务器上运行，唯一需要的更改是连接字符串，但现在这将是一个两层解决方案？
这就是为什么我觉得层的概念更多的是关于在单独的机器上运行它们的能力，而不是实际上必须这样做。 对我来说这似乎更加一致。
A separate logical layer is enough for me to call it a tier. It doesn't necessarily have to be on a separate server but the defined separation from other layers certainly makes it possible.
As an example we used to have what I would call a 3 tier system (db, dll, asp pages) running on a single server. By some definitions this is a single tier system. We now have the database running on a separate server, the only change required was a connection string but now this would be a two tier solution?
That is why I feel the concept of a tier is more about the ability to run them on separate machines rather than actually having to. It just seems more consistent to me.
对我来说，物理层意味着系统的一部分，设计在不同的物理机器上运行。 是的，您可以随时将数据库连接字符串指向另一台服务器，但是如果您的 DAL 太频繁，有 n+1 和无界记录集问题，那么网络延迟会很快杀死您。
另一方面，逻辑层支持关注点分离、内聚和耦合的优点。 严格来说，它甚至不必位于单独的程序集中 - 命名空间就可以解决问题。 只是不要调用您知道不应该调用的类，NDepend 会帮助您。
For me, physical tier means part of the system, designed to be run on different physical machine. Yes, you can point your db connection string to another server at any time, but if your DAL is too chatty, has n+1 and unbounded record set problems, than network latency will kill you really fast.
Logical layer, on the other hand, supports virtues of separation of concerns, cohesion and coupling. Strictly it doesn't even have to be in separate assembly - namespace will do the trick. Just do not call classes you know you shouldn't, NDepend help you.
参考。
Ref.
层是一种最小化耦合的机制； 他们是合乎逻辑的。 各层旨在最大限度地提高性能或消除安全风险； 他们是身体上的。 它们确实不一样，我不确定为什么人们试图互换使用它们。
绝大多数 Web 应用程序默认为 3 层（浏览器、Web 服务器、数据库服务器）。 大多数 Intranet 应用程序都是两层的（客户端、数据库服务器）。 但无论哪种情况，我都会构建一个 UI 层、一个业务层和一个数据层。 它们实现了关注点分离，并帮助我构建代码以实现可维护性。 无论哪种情况，我通常都会将它们全部部署在一个盒子上； Web 服务器或客户端工作站。 所以层和层甚至不匹配。
Layers are a mechanism for minimizing coupling; they are logical. Tiers are designed to maximize performance or negate security risks; they are physical. They really aren't them same and I'm not sure why people try to use them interchangeably.
The vast majority of web applications are 3 tier by default (browser, web server, database server). The majority of intranet apps are 2-tier (client, db server). But in either case I build a UI layer, a business layer, and a data layer. They have separation of concerns and help me structure my code for maintainability. Also in either case I usually end up deploying them all on one box; web server or client workstation. So the layers and the tiers don't even match up.
我一直认为层是架构中的任何物理分离，也就是说，一台机器。 我发现这些人最近也有同样的想法，这是一本非常好的书。
但在阅读其他回复后仔细思考，我同意加里的观点这一点。
I always believed a tier is any physical separation in an architecture, that means, a machine. I found that these guys think the same lately, it's a very good book.
But thinking well after reading the other responses I agree with Garry on that.
我同意 Garry Shutler 的观点，但补充说，单个进程/线程甚至同一个程序集中也可能存在许多层。 比物理（硬件、可执行文件隔离或二进制隔离）分离更重要的是开发人员的代码布局（恕我直言）。 与 aspnet 应用程序一样：同一个 dll 可以包含所有三层：数据访问、域和表示。
i would concur with Garry Shutler but add that many tiers might also exist in a single process/thread or even the same assembly. more important than the physical (hardware, executable isolation, or binary isolation) separation is the layout of the code for the developer (IMHO). as in with a aspnet app: the same one dll could have all three tiers in it: data access, domain and presentation.
我不得不说，这些定义需要敲定。 我通常将层视为功能和职责的逻辑分离，将层视为物理分离的要求或能力。 一些层可以具有多个层并且一些层可以跨层。 我通常使用服务层，它能够在必要和/或需要时通过配置提供物理隔离。
因此，请跟进问题/评论。 如果数据库中的存储过程中有一堆逻辑（业务或其他），那么它也应该被视为一个层吗？ 如果您正在利用数据库引擎的功能（例如 Service Broker for Microsoft SQL Server）怎么办？ 这可以被视为本身具有两层。
另外，后台服务和/或守护进程，它们是单独的层和/或层还是属于现有层？
I would have to say that the definitions need to be hammered out. I typically think of a tier as a logical separation of functionality and responsibility and a layer as the requirement or ability for a physical separation. Some layers may have multiple tiers and some tiers may span layers. I typically use a service layer tier that has the ability to provide physical separation if necessary and/or desired via configuration.
So, follow up question/comment. If there is a bunch of logic (business or otherwise) in stored procedures in your database, should that be considered a tier as well? What if you are utilizing features of your database engine like Service Broker for Microsoft SQL Server? That can be viewed as having two tiers itself.
Also, background services and/or daemons, are they a separate tier and/or layer or do they belong to an existing one?
看看术语“层”在计算中的历史。 没有人说台式机/迷你机/大型机上的一级计算。 在客户端-服务器时代，没有人谈论两层计算。 三层成为客户端-服务器加上中间件（面向消息的中间件和事务代理）的架构绰号。 我认为 n 层是与另一个术语“EAI - 或企业架构集成”一起流行起来的。 这与面向服务的架构完全相同，只是大多数供应商的实现要么是专有的、基于标准的但非常昂贵，要么两者兼而有之。 XML-RPC、SOAP 和 REST 出现后，他们将其称为“Web 服务”，然后应用其背后的 EAI 原则，提出 SOA——面向服务的架构和企业服务总线。
我的观点是，这些术语都不意味着任何物理分离……它始终与功能的逻辑分离有关。 碰巧的是，许多逻辑应用程序层被设计为无状态，因此可以出于水平可扩展性的目的在物理上分离它们。
Look at the history of the term "tier" in computing. No one said 1-tier computing on desktops/minis/mainframes. No one said 2-tier computing during the client-server days. 3-tier became the architectural moniker for client-server plus middleware in between (message oriented middleware and transaction brokers). I think n-tier was popularized along with another term "EAI - or Enterprise Architecture Integration". It was precisely the same idea as service-oriented architectures, except most of the vendor implementations were either proprietary, standards based but very expensive, or both. After XML-RPC, SOAP, and REST come along they call it "Web Services" and then apply the EAI principle behind it and come up to SOA - Service Oriented Architecture and Enterprise Service Bus.
My point is that none of these terms implied any physical separation... it was always about the logical separation of functionality. It just so happened that many of these logical application layers were designed to be stateless so that they COULD be physically separated for the purpose of horizontal scalability.