“Layers”和“Tiers”的区别是什么?


当前回答

为什么总想用复杂的词?

一层=你的代码的一部分,如果你的应用程序是一个蛋糕,这是一片。

一层=一台物理机器,一台服务器。

一个层承载一个或多个层。


层的例子:

表示层=通常是所有与用户界面相关的代码 数据访问层=与数据库访问相关的所有代码

层:

你的代码托管在服务器上=你的代码托管在一个层上。

你的代码托管在2个服务器上=你的代码托管在2层上。

例如,一台机器承载Web站点本身(表示层),另一台机器更安全地承载所有更安全的代码(真正的业务代码-业务层、数据库访问层等)。


实现分层架构有很多好处。这很棘手,正确实现分层应用程序需要时间。如果你有一些,看看微软的这篇文章:http://msdn.microsoft.com/en-gb/library/ee658109.aspx

其他回答

我使用层来描述我的解决方案组件中的架构师或技术堆栈。通常在涉及网络或进程间通信时,我使用层对这些组件进行逻辑分组。

我喜欢下面来自微软应用程序架构指南2的描述

层描述了应用程序中功能和组件的逻辑分组;而层描述了功能和组件在独立服务器、计算机、网络或远程位置上的物理分布。尽管层和层使用相同的名称集(表示、业务、服务和数据),但请记住,只有层意味着物理分离。

为什么总想用复杂的词?

一层=你的代码的一部分,如果你的应用程序是一个蛋糕,这是一片。

一层=一台物理机器,一台服务器。

一个层承载一个或多个层。


层的例子:

表示层=通常是所有与用户界面相关的代码 数据访问层=与数据库访问相关的所有代码

层:

你的代码托管在服务器上=你的代码托管在一个层上。

你的代码托管在2个服务器上=你的代码托管在2层上。

例如,一台机器承载Web站点本身(表示层),另一台机器更安全地承载所有更安全的代码(真正的业务代码-业务层、数据库访问层等)。


实现分层架构有很多好处。这很棘手,正确实现分层应用程序需要时间。如果你有一些,看看微软的这篇文章:http://msdn.microsoft.com/en-gb/library/ee658109.aspx

阅读Scott Hanselman关于这个问题的帖子:关于“三/多层/层架构/设计”的提醒:

请记住,在“Scott的世界”(希望也是你的世界:)中,“Tier”是一个部署单元,而“Layer”是代码中责任的逻辑分离。你可能会说你有一个“三层”系统,但在一台笔记本电脑上运行它。你可能会说你有一个“三层”系统,但只有ASP。与数据库对话的NET页。精准就是力量,朋友们。

从技术上讲,Tier可以是代码运行所需的一种最小环境。

例如,假设一个3层应用程序可以运行

3 physical machines with no OS . 1 physical machine with 3 virtual machines with no OS. (That was a 3-(hardware)tier app) 1 physical machine with 3 virtual machines with 3 different/same OSes (That was a 3-(OS)tier app) 1 physical machine with 1 virtual machine with 1 OS but 3 AppServers (That was a 3-(AppServer)tier app) 1 physical machine with 1 virtual machine with 1 OS with 1 AppServer but 3 DBMS (That was a 3-(DBMS)tier app) 1 physical machine with 1 virtual machine with 1 OS with 1 AppServers and 1 DBMS but 3 Excel workbooks. (That was a 3-(AppServer)tier app)

Excel工作簿是运行VBA代码所需的最低环境。

这3个工作簿可以放在一台物理计算机上,也可以放在多个物理计算机上。

我注意到,在实践中,人们在应用描述上下文中说“层”时,指的是“操作系统层”。

也就是说,如果一个应用运行在3个不同的操作系统上,那么它就是一个3层应用。

所以从学究角度来说,描述应用程序的正确方法是

“1至3层能力,运行在2层”应用程序。

:)


层只是应用程序中职责功能分离的代码类型(例如,表示,数据,安全等)。