三层架构有用吗？
我们构建三层架构已有十多年了。划分表示层、逻辑层和数据层应该允许我们在需要时单独交换每一层，无论是通过改变的需求还是新技术。
我从未见过它在实践中发挥作用...
主要是因为（至少）以下原因之一：
- 三层概念仅在源代码中可见（例如，Java 中的包命名），然后将其部署为一个捆绑在一起的包。
- 代表每一层的代码都以其自己的可部署格式很好地捆绑在一起，然后放入同一进程中（例如“企业容器”）。
- 每一层都在自己的进程中运行，有时甚至在不同的机器上运行，但通过静态性质，它们相互连接，替换其中一层意味着破坏所有层。
因此，您通常最终得到的是一个整体的、紧密耦合的系统，该系统无法实现其架构所承诺的功能。
因此，我认为“三层架构”完全是用词不当。它带来的真正好处是代码逻辑合理。但这是在“写入时”，而不是“运行时”。更好的名字应该是“按责任分层”。无论如何，“架构”这个词是有误导性的。
您对此有何看法？如何实现三层架构的工作？我的意思是一个信守诺言的层：允许插入一层而不影响其他层。系统应该能够存活下来，并且之后处于明确定义的状态。
谢谢！
We are building three-tier architectures for over a decade now. Dividing presentation-, logic- and data-tier is supposed to allow us to exchange each layer individually, should the need ever arise, be it through changed requirements or new technologies.
I have never seen it working in practice...
Mostly because (at least) one of the following reasons:
- The three tiers concept was only visible in the source code (e.g. package naming in Java) which was then deployed as one, tied together package.
- The code representing each layer was nicely bundled in its own deployable format but then thrown into the same process (e.g. an "enterprise container").
- Each layer was run in its own process, sometimes even on different machines but through the static nature they were connected to each other, replacing one of them meant breaking all of them.
Thus what you usually end up with, in is a monolithic, tightly coupled system that does not deliver what it's architecture promised.
I therefore think "three-tier architecture" is a total misnomer. The true benefit it brings is that the code is logically sound. But that's at "write time", not at "run time". A better name would be something like "layered by responsibility". In any case, the "architecture" word is misleading.
What are your thoughts on this? How could working three-tier architecture be achieved? By that I mean one which holds its promises: Allowing to plug out a layer without affecting the other ones. The system should survive that and be in a well defined state afterwards.
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
分层架构（逻辑层和物理层）的真正目的不是使替换层变得容易（这种情况很少见），而是使层内的更改变得容易，而无需影响其他人（以及正如Ben指出的，以促进可扩展性、一致性和安全性）——它一直在我们周围发挥作用。
The true purpose of layered architectures (both logical and physical tiers) isn't to make it easy to replace a layer (which is quite rare), but to make it easy to make changes within a layer without affecting the others (and as Ben notes, to facilitate scalability, consistency, and security) - which works all the time all around us.
3 层架构的一个示例是典型的数据库驱动的 Web 应用程序：
One example of a 3-tier architecture is a typical database-driven web application:
在每个系统中，都有一开始梦想的美好、优雅的架构，然后是最终投入生产时的混乱，充满了数百个错误修复和特殊情况处理程序，以及为解决未实现的特定问题而进行的其他典型的令人讨厌的更改在设计过程中。
我认为您所描述的问题根本不是三层架构特有的。
In every system, there is the nice, elegant architecture dreamed up at the beginning, then the hairy mess when its finally in production, full of hundreds of bug fixes and special case handlers, and other typical nasty changes made to address specific issues not realized during the design.
I don't think the problems you've described are specific to three-teir architecture at all.
如果你还没有看到它起作用，那你可能只是运气不好。我曾参与过通过一个 Web 服务（逻辑）为多个 UI（演示）提供服务的项目。此外，我们通过配置（数据）交换了数据提供者，因此我们可以在更高环境中开发 Oracle 时使用低成本数据库。
当然，总会有一些重复 - 也许您在 UI 中添加验证以提高响应能力，然后在逻辑层中再次验证 - 但总的来说，干净的分离是可能的，并且使用起来很好。
If you haven't seen it working, you may just have bad luck. I've worked on projects that serve several UIs (presentation) from one web service (logic). In addition, we swapped data providers via configuration (data) so we could use a low-cost database while developing and Oracle in higher environments.
Sure, there's always some duplication - maybe you add validation in the UI for responsiveness and then validate again in the logic layer - but overall, a clean separation is possible and nice to work with.
一旦您承认 n 层的主要优点（即可扩展性、逻辑一致性、安全性）无法通过其他方式轻松实现，那么是否可以在不破坏其他层的情况下直接替换任何层的问题就变得更加重要就像问是否有锦上添花一样。
Once you accept that n-tier's major benefits--namely scalability, logical consistency, security--could not easily be achieved through other means, the question of whether or not any of the tiers can be replaced outright without breaking the the others becomes more like asking whether there's any icing on the cake.
任何操作系统都会有类似的架构，否则它将无法工作。表示层独立于硬件层，硬件层被抽象为实现某个接口的驱动程序。数据的处理逻辑会根据读取的数据类型而变化（例如 NTFS、FAT32、EXT3 和 CD-ROM）。 Linux 几乎可以在任何您可以使用的硬件上运行，并且它的外观和行为仍然相同，因为层之间的抽象将彼此与单层内的更改隔离开来。
Any operating system will have a similar kind of architecture, or else it won't work. The presentation layer is independent of the hardware layer, which is abstracted into drivers that implement a certain interface. The data is handled using logic that changes depending on the type of data being read (think NTFS vs. FAT32 vs. EXT3 vs. CD-ROM). Linux can run on just about any hardware you can throw at it and it will still look and behave the same because the abstractions between the layers insulate each other from changes within a single layer.
三层方法最大的实际好处之一是它可以轻松地划分工作。您可以轻松地让一名 DBA 和一名或两名业务人员构建数据层，一名传统程序员构建服务器端应用程序代码，以及一名图形设计师/网页设计师构建 UI。当然，三个团队仍然需要沟通，但这在大多数情况下可以让开发更加顺利。在这方面，我认为三层方法每天都可靠地工作，这对我来说已经足够了，即使我不能指望“可互换的部件”，可以这么说。
One of the biggest practical benefits of the 3-tier approach is that it makes it easy to split up work. You can easily have a DBA and a business anylist or two building a data layer, a traditional programmer building the server side app code, and a graphic designer/ web designer building the UI. The three teams still need to communicate, of course, but this allows for much smoother development in most cases. In this regard, I see the 3-tier approach working reliably everyday, and this enough for me, even if I cannot count on "interchangeable parts", so to speak.