2009-10-25 143 views
9

我们真正需要3层架构的例子是什么?大多数使用3层架构的应用程序是否可以使用2层架构来完成?3层架构vs 2层架构

注:我想看到3层架构的价值,我觉得大部分的应用程序,有3层,现在可以在2层来完成,所以我找实例,我们绝对需要3这种需求并没有例外。

+1

*“我找实例,其中我们绝对需要3层,没有例外“* - 这个行业真的没有什么是明确的。事实上,有几百种方法来处理每一个问题,任何方法都有其自身的优点。人们已经做了这么长时间,以至于某些方法出现,这些方法在经验上解决了比他们创造的更多问题 - 而这些方法成为行业准则/模式/最佳实践。相信在任何情况下,一种方法是绝对正确的,而另一种方法是绝对错误的,这是一种谬论。 – MattDavey 2013-04-22 08:25:28

回答

6

我猜你的意思是分层(分离的逻辑单元)而不是分层(物理单元的分离/部署)。分层系统的一个例子是一个网页服务器(1层)提供网页(另一层),它从第三层的数据库中提取数据。

分层架构的通常目标是分离责任。这有两个关键的好处(其中包括)。

首先,您的设计将更清晰,责任不会混淆,因此代码将更易于阅读,理解和维护。

其次,您可能会减少重复 - 例如,如果您的页面也在处理业务逻辑(或恐怖数据访问的恐怖)以及显示页面,则可以在Web应用程序中实现,多个页面将尝试做相同或类似的事情。

你并不需要建筑师(例如成层,虽然也有其他方式)的任何一款软件,但是从琐碎的事情除了东西如果不这样做的结果将是一个不可维护的混乱。

-1

那么,如果你有一个网站...你可能有一些Javascript代码,所以这是一个层,你有你的业务逻辑在服务器,你有数据库来存储的东西。我认为这是三层。当然,你可以在数据库中使用存储过程并跳过业务逻辑层,这样可以建立一个两层的网站,但如果你不想使用存储过程,你将有三层。

+1

业务逻辑不应该驻留在存储过程或数据访问层中。我更喜欢将数据库视为对象 - 存储过程的方法以及作为数据实体的字段。存储过程以最有利的方式处理从数据库中获取数据以及实现SQL自身的任务 - 例如,基于多条记录上的连接更新列。 – 2009-10-25 16:16:19

+0

@ztech,是啊,那么......?每个人都有偏好和观点以及'不应该'。与OP的问题有什么关系? – tuinstoel 2009-10-25 17:26:28

+2

关键是鼓励良好的设计实践。例如,如果有人问如何将超过512个文件放入Windows 95的根目录中,我的第一个回应是“不要,因为这是一个坏主意。”试图巩固你的应用中的图层几乎总是一个坏主意,而我,其中一个,不想结束后来出现的那个人,并且必须保持那种废话。不鼓励业内糟糕的设计让我们的生活变得更轻松。 – 2009-10-25 22:18:23

3

道具FinnNk,但让我给你一个例子,当你不分层时会发生什么。多年来,我一直在做一个在出生时严重分离的项目。所有三层 - 如果您相信tuinstoel所说的话 - 更多的是集中到各个JSP页面。我相信它当时看起来是一个聪明的东西(当你刚开始的时候编码会更快),但是这个怪物已经增长和增长,没有人花时间重构。

我们现在有2000多个JSP页面,其中遍布着重复的代码。改变模式需要仔细回溯,找出可能影响的页面,并对每个页面进行单独测试。管理层中没有人认为重要的是花时间来解决这个问题 - 短期收益,长期亏损。

做。不。走。这个。路线。

分离层导致更好,更快,更可测试,更模块化的代码。你会为此感谢你,并且(更重要的)你会感谢你的人。

2

某些数据库向外界展示了一个休息界面,例如NoSQL数据库CouchDB和RavenDB。这意味着浏览器中运行的Javascript可以在没有中间层的情况下调用数据库。

参见例如:http://www.infoq.com/news/2010/06/couchdb

“表现良好HTTP/REST接口和 API清洁和简单的两层 应用程序(HTML + JavaScript中的 浏览器+榻+ JavaScript作为服务器)”

Oracle内部有一个Web服务器,您可以使用存储的特效,同时向外界展示休息界面。因此,浏览器中的JavaScript也可以在没有中间层的情况下调用Oracle数据库。

你是否总是需要一个中间层,当你想要从数据库中获取一些数据?我质疑这种需要。

(TTT原名Tuinstoel)

+0

只是好奇,你在这种情况下如何处理安全?我很好奇。 – 2010-09-01 00:40:01

0

可能会推动你摆脱2层至3层的一些情况: 1 - 您的系统拥有不同类型的客户端(台式机,网络,手机等) 2-您的系统具有不同类型的数据源(例如,非数据库资源)
3-您的系统需要特定的客户端/服务器通信协议 4-您希望隐藏和保护客户端的数据层 5-您需要服务器集群和负载均衡的可扩展性 6-您需要服务器到服务器的集成,对客户端来说是透明的 7-您希望将共享资源用于多个客户端(例如数据库连接) 8-您希望通过将客户端从数据库服务器或服务器组中解耦来简化系统维护9-您希望将业务逻辑放入单独的层在特定平台上 10-您希望减少客户端和数据库之间的流量

0

首先,很好的问题。正如其他人所指出的,两者都有优点。 “关注的分离 - ”是3层的主要优点和几种方法,支付股息:

  1. 安全性:通过从演示分开你的业务逻辑,则可以采取更为严格的政策,各个层例如没有数据或逻辑的演示文稿表单可以位于演示文稿区域,这样匿名用户就可以访问您的“公开”内容。
  2. 可维护性/可管理性 - 已经对此说过很多
  3. 重复使用/灾难恢复:例如,如果一个治疗管理应用可能想要公开一个UI以及第三方可用来发出处方订单的服务。按业务逻辑分离成一个单独的层,可以独立于UI

有几个人的维护服务/逻辑,但这些希望得到的潜在好处的想法