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