多年来，我注意到不同的开发人员在开发 n 层系统时对层的构成有不同的标准，所以我很好奇 stackoverflow 的共识是什么。
单独的逻辑层是否足以将其称为单独的层，还是必须可部署在单独的服务器（物理或虚拟）上才能将其称为单独的层？
让我用不同的方式来表达这个问题。如果调用机制只能在进程、线程本地或单元本地，那么根据类如何组织到库或包中，是否可以声称它是两个不同的层？
【问题讨论】：
标签： architecture n-tier-architecture
一个单独的逻辑层足以让我称之为层。它不一定必须在单独的服务器上，但定义的与其他层的分离肯定使它成为可能。
作为一个例子，我们曾经有一个运行在单个服务器上的 3 层系统（db、dll、asp 页面）。根据某些定义，这是一个单层系统。我们现在让数据库在单独的服务器上运行，唯一需要更改的是连接字符串，但现在这将是一个两层解决方案？
这就是为什么我觉得层的概念更多的是关于在单独的机器上运行它们的能力，而不是实际上必须这样做。对我来说，这似乎更一致。
【讨论】：
层和层的概念是 经常互换使用。然而， 一种相当普遍的观点是 确实存在差异，并且 层是一种逻辑结构 构成要素的机制 升级软件解决方案，而一个层 是一种物理结构机制 用于系统基础架构
Ref.
【讨论】：
对我来说，物理层意味着系统的一部分，设计是为了在不同的物理机器上运行。是的，您可以随时将您的数据库连接字符串指向另一台服务器，但是如果您的 DAL 太健谈，有 n+1 和无限记录集问题，那么网络延迟会很快杀死您。
另一方面，逻辑层支持关注点分离、内聚和耦合的优点。严格来说，它甚至不必在单独的程序集中——命名空间就可以了。只是不要调用你知道不应该调用的类，NDepend 帮助你。
【讨论】：
层是一种最小化耦合的机制；他们是合乎逻辑的。层级旨在最大限度地提高性能或消除安全风险；他们是物理的。它们真的不一样，我不确定为什么人们会尝试互换使用它们。
绝大多数 Web 应用程序默认为 3 层（浏览器、Web 服务器、数据库服务器）。大多数 Intranet 应用程序是 2 层（客户端、数据库服务器）。但无论哪种情况，我都会构建一个 UI 层、一个业务层和一个数据层。他们有关注点分离并帮助我构建我的代码以实现可维护性。同样在任何一种情况下，我通常最终都将它们全部部署在一个盒子上； Web 服务器或客户端工作站。所以层和层甚至不匹配。
【讨论】：
我同意 Garry Shutler 的观点，但补充说许多层也可能存在于单个进程/线程甚至同一个程序集中。比物理（硬件、可执行隔离或二进制隔离）分离更重要的是开发人员的代码布局（恕我直言）。与 aspnet 应用程序一样：同一个 dll 中可能包含所有三层：数据访问、域和表示。
【讨论】：
我不得不说这些定义需要敲定。我通常认为层是功能和责任的逻辑分离，层是物理分离的要求或能力。有些层可能有多个层，有些层可能跨越层。我通常使用能够在必要和/或需要时通过配置提供物理分离的服务层。
所以，跟进问题/评论。如果数据库中的存储过程中有一堆逻辑（业务或其他），是否也应该将其视为一个层？如果您正在使用 Microsoft SQL Server 的 Service Broker 等数据库引擎的功能怎么办？这可以被视为本身有两个层次。
此外，后台服务和/或守护程序是单独的层和/或层还是属于现有层？
【讨论】：
查看计算中“层”一词的历史。没有人说台式机/小型机/大型机上的 1 层计算。在客户端-服务器时代，没有人说 2 层计算。 3 层成为客户端-服务器加上中间件（面向消息的中间件和事务代理）之间的架构名称。我认为 n 层是与另一个术语“EAI - 或企业架构集成”一起普及的。这与面向服务的架构完全相同，只是大多数供应商的实现要么是专有的、基于标准的但非常昂贵，要么两者兼而有之。在 XML-RPC、SOAP 和 REST 出现之后，他们将其称为“Web 服务”，然后应用其背后的 EAI 原则并提出 SOA——面向服务的体系结构和企业服务总线。
我的意思是，这些术语都没有暗示任何物理分离......它总是关于功能的逻辑分离。碰巧的是，这些逻辑应用层中的许多都被设计为无状态的，因此它们可以在物理上分离以实现水平可扩展性。
【讨论】：