所以我一直在学习建筑风格和模式。据我所知，当涉及到 3 层架构时，大多数人都在使用一种模式（例如 MVC）。但我的问题是，是否有人只使用没有任何模式的普通老式 3 层双向架构？这在行业中是否已实践甚至可以接受？
【问题讨论】：
标签： design-patterns model-view-controller architecture 3-tier
架构应该
形式一致
层，如Code Complete, 2nd Edition 中所述。仅仅拥有architectural patterns and styles 中的任何一个（MVC 实际上是Multitier architecture 的业务层的一部分）是不够的。视需求而定
简单的旧式 3 层双向架构
可能最适合客户端-服务器分布式系统。记住 - 过度设计和没有设计一样糟糕。
因此，作为底线 - 在所有级别上保持 good practices、SOLID 和 design patterns 原则，才是好的软件。
【讨论】：
如果您指的是大多数开发人员在使用术语“3 层架构”时所做的概括，可能不像以前那么多。
这是什么意思？
嗯，根据我的经验，“3 层架构”的含义是围绕使用大致分为 3 个主要抽象（或“层”/层）的系统设计进行概括：
问题只是这个结构没有很好地定义，所以我认识的大多数人都会犹豫以这种方式描述他们的系统设计。这意味着什么太主观了，所以很容易被误解。
在许多简单的情况下，其中一些抽象可能是不必要的。今天的各种持久性模式（例如Table Gateway）和ORM 库使得以“对象友好”的方式存储和混合数据变得非常容易，这意味着调用封装这项工作的代码可能是一个完整的“层”有点过头了。
此外，简单的CRUD 应用程序可能根本没有什么“业务逻辑”，而且由于 ORM 在许多情况下可以愉快地促进 CRUD，因此没有任何特定于业务的逻辑可言，因此呈现了这部分系统作为“层”也相当多余。
用户界面可能是这三个中唯一真正站在其上的“层”几乎在所有情况下都在 IMO 上。
如果系统具有复杂的业务/领域逻辑，那么Domain Model 或其他DDD 模式可能会发挥作用。在复杂的系统中，通常使用可靠的 ORM 工具来简化数据接口的工作。尽管如此，我的同事通常不会通常将这些元素称为“层”——它们会更具体并明确命名design patterns，以便解释不那么主观。我们当然不会使用“3 层架构”之类的术语。
HTH
【讨论】：
普通的旧 3 层架构是一种模式。
【讨论】：