我们真正需要3层架构的示例是什么？绝大多数使用3层架构的应用程序是否可以使用2层架构完成？
注意：我试图看到3层架构的价值，我觉得现在有3层架构的大多数应用程序都可以使用2层架构完成，因此我正在寻找绝对需要3层架构且没有例外需求的示例。
3层架构与2层架构
12
- Rachel
1
1“我正在寻找绝对需要三层架构且没有例外的示例。” - 实际上，在这个行业中没有什么是那么明确的。实际上，有数百种方法来解决每一个问题，每种方法都有其自身的优点。人们已经做了足够长的时间，以至于某些方法会出现，这些方法在经验上解决的问题比它们创造的问题更多 - 这些方法成为行业指南/模式/最佳实践。认为在任何给定的情况下，一种方法绝对正确而另一种方法绝对错误是一种谬论。 - MattDavey
5个回答
7
我猜你的意思是分层（逻辑上的分离单元），而不是分层（物理上的分离/部署单元）。分层系统的一个例子是Web服务器（1层）提供Web页面（另一层），这些页面依赖于来自数据库的数据（第3层）。
分层架构的通常目的是将责任分开。这有两个主要优点（还有其他优点）。
首先，你的设计会更清晰，因为责任不会混淆，代码会更容易阅读、理解和维护。
其次，你很可能会减少重复——例如，在Web应用程序中，如果你的页面也处理业务逻辑（或者更糟糕的是数据访问），并显示页面，那么你可以相当肯定地认为多个页面将尝试做相同或类似的事情。
你不需要对任何软件进行架构设计（例如分层，虽然还有其他方法），但除了琐碎的东西之外，如果你不这样做，结果将是无法维护的混乱。
- FinnNk
3
致敬FinnNk，但让我举一个例子来说明当您不分离层时会发生什么。多年来，我一直在一个项目上工作，该项目在出生时分离得很差。所有三个层次 - 如果您相信tuinstoel所说的话，则更多 - 都集中在单个JSP页面中。我相信在当时看起来是个聪明的选择（当你刚开始编码时更快），但这个怪物已经越来越大，没有人花时间重构它。
现在我们有2000多个JSP页面，其中散布着重复的代码。进行模式更改需要仔细地回溯以找出可能受影响的页面，并对每个页面进行单独测试。管理层中没有人认为这很重要，可以花时间修复它 - 短期收益，长期损失。
不要采用这种方法。
分离层会导致更好，更快，更易于测试，更模块化的代码。您会感谢自己，更重要的是，接替您的人会感谢您。
现在我们有2000多个JSP页面，其中散布着重复的代码。进行模式更改需要仔细地回溯以找出可能受影响的页面，并对每个页面进行单独测试。管理层中没有人认为这很重要，可以花时间修复它 - 短期收益，长期损失。
不要采用这种方法。
分离层会导致更好，更快，更易于测试，更模块化的代码。您会感谢自己，更重要的是，接替您的人会感谢您。
- Maas
2
一些数据库向外界暴露了REST接口，例如NoSQL数据库CouchDB和RavenDB。这意味着运行在您浏览器中的JavaScript可以直接调用数据库，不需要中间层。
例如，请参见：http://www.infoq.com/news/2010/06/couchdb 引用：
"良好的HTTP/REST接口和API清晰简单的两层应用(html+javascript在浏览器和couch+javascript作为服务器)"
Oracle具有内置的Web服务器，您可以使用存储过程，这也向外部暴露了REST接口。因此，您的浏览器中的JavaScript也可以不需要中间层地调用Oracle数据库。
当您只是想从数据库获取一些数据时，您总是需要一个中间层吗？我对这种需求表示怀疑。
(TTT，曾用名Tuinstoel)
例如，请参见：http://www.infoq.com/news/2010/06/couchdb 引用：
"良好的HTTP/REST接口和API清晰简单的两层应用(html+javascript在浏览器和couch+javascript作为服务器)"
Oracle具有内置的Web服务器，您可以使用存储过程，这也向外部暴露了REST接口。因此，您的浏览器中的JavaScript也可以不需要中间层地调用Oracle数据库。
当您只是想从数据库获取一些数据时，您总是需要一个中间层吗？我对这种需求表示怀疑。
(TTT，曾用名Tuinstoel)
- TTT
1
只是好奇，你在那种情况下如何处理安全问题？我很感兴趣。 - Brian MacKay
0
首先，这是一个很好的问题。正如其他人所指出的那样，两者都有优点。"关注点分离"是3层架构的主要优势，它在多个方面都能带来回报：
- 安全性：通过将业务逻辑与表示分离，您可以对各个层应用更严格的策略，例如表示形式没有数据或逻辑可以在您的表示区域中，因此匿名用户可以访问您的“公共”内容。
- 可维护性/可管理性 - 已经有很多关于此的说法
- 重用/灾难恢复：例如，如果药房管理应用程序想要公开UI以及第三方可以使用的服务来下达处方订单。通过将业务逻辑分离到单独的层中，您可以独立地维护服务/逻辑而不影响UI。
还有其他几个，但这些希望能够给出潜在的好处的想法。
- wole bankole
-1
如果你有一个网站... 你可能有一些Javascript代码，那就是第一层，你在服务器上有你的业务逻辑和数据库来存储东西。在我看来，这是三个层次。当然，你可以在数据库中使用存储过程并跳过业务逻辑层，因此如果你想要构建一个只有两个层次的网站，那是可能的，但如果你不想使用存储过程，你将需要三个层次。
- tuinstoel
5
1业务逻辑不应该驻留在存储过程或数据访问层中。我更喜欢将数据库视为一个对象——存储过程是方法，字段是数据实体。存储过程处理以最快速的方式将数据输入和输出数据库，并实现适合SQL的任务，例如基于多个记录的连接更新列。 - 3Dave
@ztech，是啊，那又怎么样呢..？每个人都有自己的偏好和看法，还有自己的"不应该"。这和OP的问题有什么关系呢？ - tuinstoel
2重点是鼓励良好的设计实践。例如，如果有人问如何在Windows 95中将超过512个文件放入根目录中，我的第一反应将是“不要这样做，因为这是一个坏主意。”试图合并应用程序中的层几乎总是一个坏主意，我不想成为后来需要维护那些垃圾代码的人。在行业中阻止不良设计可以让我们所有人的生活更轻松。 - 3Dave
2@tuinstoel 此外，还有一种被称为“良好设计”的动物，它的确定不仅仅取决于个人喜好。 - 3Dave
我仍然不明白你所说的“数据库是一个对象”的意思，除非你认为一切都是对象？我所谈论的是使用驻留在数据库内部的Web服务器。那么你就不需要中间层了。这是否是一个好主意取决于你的需求。 - tuinstoel
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接