这是背景，也许有些条款不正确，因为我不是这方面的专家：
几年前我申请了 以下架构，以便 获得代码重用和种类 关注点分离：
- 表示层：将ASP.NET与C＃结合使用。网页逻辑是 在这里编程，但业务 逻辑在单独的层中定义
- 模型定义图层：对网站的所有业务实体进行分组 系统（即文档，用户，文件夹）。 没有动作（旁边的方法 在...上定义的getter和setter） 宾语。它只是一个记录 来自表格（或表格的连接） 数据库
- 业务逻辑层：此处的条款名为“Engines”，它们 拥有所有业务规则 每个业务实体的交互 （即DocumentEngine拥有全部 代表业务的方法 处理文件的规则 系统，如添加，删除， 更新等）。这些方法使用（如 在许多情况下返回业务实体（在模型定义上定义），在其他情况下只返回使用/返回原语。
- 数据访问层：此图层检索数据（使用数据 访问服务）来自数据库和 将转换为业务实体（创建在MDL中定义的对象的实例，并使用从DB检索的相应字段值设置其属性值）。 与业务逻辑层一样，它使用 并返回业务实体或原语 以前提到的单身 对象或对象的集合 （使用泛型）
- 数据访问服务：使用简单工厂模式创建 根据数据库连接 指定的参数，所以它可以 从多个检索信息 数据库引擎。
那么，当我需要时，例如文档列表，我打开网页，使用适当的参数调用业务规则（即本案例的文件夹ID）。然后，数据访问层使用DAS查询数据库并将检索到的记录转换为业务实体（在MDL中定义）。此业务实体（或实体集合）通过层返回到表示层。
现在，也许这不是最好的架构，但它对我来说非常好用，所以现在我尝试使用相同的方法，但使用Java和Spring MVC作为表示层，所以我会< / p>
业务要求是“创建一个企业轻量级Web应用程序，可以轻松扩展，连接到多个数据库（Oracle，SQL Server，mySQL），只需极少的代码更改，I18N支持，记录用户活动的能力，具有多个演示文稿模式（Web，Mobile），看起来非常不错，就像Web2.0应用程序XD“
你怎么看？这是一个很好的架构定义吗？我是否应该更改某些内容以符合业务要求？提前感谢您的合作
答案 0 :(得分：0)
在70年代后期，在关系数据库开始获得牵引力之后，程序化编程就是要做的事情，这将是一个很好的架构，适合使用更新的Web表示层。
在八十年代早期，面向对象的引入表明，数据和行为的分离导致更多的耦合和更少的凝聚力。分离模型定义和业务逻辑是一个坏主意。它往往来自关系数据库驱动的体系结构，它往往没有管理行为的地方。
由于RDBMS占主导地位，这些架构出现了很多。这并不能使他们变得更好。出现的主要问题是：
这些问题限制了此体系结构的可伸缩性。域驱动设计在这些方面表现更好。
此外，您的架构并未充分解决移动演示的后果。移动设备不仅仅是一个较小的屏幕，它还涉及触摸界面和有限的连接（长时间延迟，带宽和缓存很少，处理无连接）。