分层/分层架构 - 代码分离答案

【问题标题】：Layered/Tiered Architecture - Segregation of code分层/分层架构 - 代码分离
【发布时间】：2015-01-15 20:23:19
【问题描述】：

从最近几个月开始，我一直在使用 spring-mvc 开发企业应用程序。我听说过具有这些层/层的 3 层架构 - UI、业务逻辑 和 DAO。 我知道这种架构。但是在处理一些spring-mvc 企业项目时，我发现了一些这样的层（基于代码流） -

 Controller  
    |
    v  
 Service  
    |  
    v
 Manager  
    |  
    v
   Dao

我发现上面的分层结构与 3 层架构相比有点混乱。因为我发现service和manager层都写了一些业务逻辑。混淆可能是由于缺乏护理造成的，或者没有其他选择，而是这样做。但就像三层架构一样，每一层背后可能都有一些原因。有人可以解释为什么这些层吗？

根据stackoverflow 的规范，这可能不是一个好问题。但这对于像我这样的新开发人员来说，作为一个建议/提示，将非常有用。
谢谢。

【问题讨论】：

ports and adapters 是比图表中建议的线性方法和您提到的 3 层方法更好的架构替代方案。

标签： java oop spring-mvc design-patterns architecture

【解决方案1】：

我已经实现了一个与您描述的非常相似的设计。我的理由是“管理器”层有助于将任何特定的数据访问代码从服务层抽象出来。

所以一个看起来像这样的服务（伪代码）：

function getCustomer(id) {
    sql = "select * from customer where id = @id";
    return db->execute(sql, id);
}

最终看起来像这样：

function getCustomer(id) {
   return dbo->getCustomerById(id);
}

这个额外的层为我的项目做了一些事情。它集中了所有数据访问，允许我在其他项目中使用管理器类。它还让我可以选择（天堂禁止）更轻松地在不同的数据存储策略（结构化 sql -> nosql）之间切换，而无需更改我的任何服务层代码。

【讨论】：

当“Manager”包含 SQL 语句时，你的 DAO 中有什么？
它不是一个完美的例子，但我的 dao 将是存储库，经理将协调存储库并构建我的聚合。
@Zach Spencer 所以我们可以说我们可以在这里使用 manager 类来控制/管理数据访问和 service 用于业务逻辑？
@Razib 当然，在这个例子中这就是目的。

【解决方案2】：

这是一种 MVC（模型-视图-控制器）架构，而不是较旧的（但仍被广泛使用的）数据 - 业务逻辑 - UI 模型。它们只是不同的架构模型，虽然它们可以并且被比较和对比，但它们绝对不会一一对应。如果你发现自己正在从事一个使用 MVC 的项目，我强烈建议你找一本关于 MVC（甚至特别是关于 Spring-MVC）的书并进行一些学习。

【讨论】：