Question

从过去几个月开始，我一直在使用spring-mvc开发企业应用程序。我听说过这些层/层的3层架构 - 用户界面，业务逻辑和 DAO。这个架构对我来说是已知的。但是在处理一些spring-mvc企业项目时，我发现了一些像这样的层（基于代码流） -

 Controller  
    |
    v  
 Service  
    |  
    v
 Manager  
    |  
    v
   Dao

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

根据stackoverflow的规范，这可能不是一个好问题。但这对我这样的新开发者来说是一个很有帮助的建议/提示感谢。

Answer 1

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

Answer 2

我实施的设计与您描述的设计非常相似。我的理由是“Manager”层有助于从服务层抽象出任何特定的数据访问代码。

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

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

最终看起来像这样：

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

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

分层/分层体系结构 - 代码分离

2 个答案: