这个架构定义好吗？多层（Spring / Multi DB）

Question

这是背景，可能有些术语不正确，因为我不是这方面的专家：

我几年前申请了 遵循架构，为了 获得代码重用和种类 关注点分离：

• 表示层：将 ASP.NET 与 C# 结合使用。网页逻辑是 在这里编程，但业务 逻辑在单独的层中定义
• 模型定义层：对所有业务实体进行分组 系统（即文档、用户、文件夹）。 没有动作（方法旁边 getter 和 setter) 定义在 目的。它只代表一个记录 从表（或表的连接）中 数据库
• 业务逻辑层：这里的类被命名为“Engines”，它们 拥有所有业务规则 每个业务实体的交互 （即 DocumentEngine 拥有所有 代表业务的方法 文件处理规则 系统，如添加、删除、 更新等）。这些方法使用（如 参数）并在许多情况下返回业务实体（在模型定义上定义），在其他情况下只使用/返回原语。
• 数据访问层：该层检索数据（使用 Data 访问服务）从数据库和 convert 将其转换为业务实体（创建在 MDL 中定义的对象的实例，并使用从 DB 中检索到的相应字段值设置其属性值）。 与业务逻辑层一样，它使用 并返回业务实体或原语 前面提到的单 对象或对象集合 （使用泛型）
• 数据访问服务：使用简单工厂模式，创建 数据库连接根据 指定的参数，所以它可以 从多个检索信息 数据库引擎。

然后，当我需要文档列表时，我打开网页，使用适当的参数（即本案例的文件夹 ID）调用业务规则。然后数据访问层使用 DAS 查询数据库并将检索到的记录转换为业务实体（在 MDL 中定义）。该业务实体（或实体集合）通过层返回到表示层。

现在，也许这不是最好的架构，但它对我来说效果很好，所以现在我尝试使用相同的方法，但使用带有 Spring MVC 的 Java 作为表示层，所以我将拥有

• 演示文稿（Spring MVC）
• 模型定义层
• 业务逻辑层
• 数据访问层
• 数据访问服务（使用 JDBC 的数据库工厂）

业务需求是“创建一个企业轻量级 Web 应用程序，可以轻松扩展，连接到多个数据库（Oracle、SQL Server、mySQL），代码更改最少，支持 I18N，记录用户活动的能力，有多个演示文稿模式（Web、Mobile），看起来很像 Web2.0 应用程序 XD"

你怎么看？这是一个好的架构定义吗？我是否应该更改某些内容以符合业务要求？

提前感谢您的合作

Answer 1

在 70 年代末期，就在关系数据库开始受到关注，并开始进行过程编程之后，这本来是一个很好的架构，适合使用较新的 Web 表示层。

八十年代初，面向对象的引入表明，数据和行为的分离导致更多的耦合和更少的内聚。模型定义和业务逻辑的分离是一个坏主意。它往往来自关系数据库驱动的架构，这些架构往往没有地方管理行为。

由于 RDBMS 的主导地位，这些架构出现了很多。这并不能使他们变得好。出现的主要问题是：

• 在多个层中重复相同的关注点；
• 将验证功能与其操作的数据分开，导致数据质量不佳；
• 由于连接性能不佳，标准化不足。

这些问题限制了此架构的可扩展性。领域驱动设计在这些方面表现更好。

此外，您的架构没有充分解决移动演示的后果。移动设备不仅仅是一个较小的屏幕，它还涉及触摸界面和有限的连接（长延迟、小带宽和缓存、处理无连接）。