如何组织控制器、服务和数据访问层（Dao）

Question

我有一个Java REST API，应用程序有三个层：

Controller -> public String storeInfo(JsonModel jsonModel)
Service -> public String store(InfoEntity entity)
Dao -> public String store(InfoEntity entity)

现在，我意识到这个“服务”并没有太多的工作要做，只是来回发送请求。后来我发现这是因为“Dao”和“service”具有相同的接口。

所以，我进行了更改：

Controller -> public String storeInfo(JsonModel jsonModel)
Service -> public String store(JsonModel jsonModel)
Dao -> public String store(InfoEntity entity)

现在，“服务”有更多的工作要做。它必须将输入数据映射到要存储到数据库中的实体。它从另一个对象获得帮助，但这是它的责任。

然而，现在我意识到“jsonModel”对象具有更多信息，不仅仅是保存的信息。例如，访问我的API需要用户名和密码。这是控制器的责任。也许我向“服务”发送了太多信息。

因此，我进行了以下更改：

Controller -> public String storeInfo(JsonModel jsonModel)
Service -> public String store(TransferObject transferObject)
Dao -> public String store(InfoEntity entity)

但后来我意识到我现在有三个不同的对象，这意味着我必须进行两种不同的映射。大量代码看起来过度设计了。

我应该如何改变现在，使其简单且功能有效？

- user1883212

Answer 1

你的中间选项不错，但是我会有一个特定的Info模型，它不会被你应用程序的用户名和密码污染。

Controller -> public String storeInfo(Info info)
Service -> public String store(Info info)
Dao -> public String store(InfoEntity entity)

通常情况下应该避免使用三个bean。在过去中，我发现两个bean是最好的选择 - 就像这个例子。

另一种方法是在每一层使用相同的bean。但我很讨厌这种方法。
这会让你得到一个包含Hibernate注释、JSON注释、验证注释、多个构造函数、不同日期格式等信息的单个 Info bean。看起来非常混乱。
我提到这点只是因为这种方法经常被网上的示例和书籍推荐。但实际上只有当你的数据库、用户界面和业务表示完全相同时才能使用，而在现实世界中，这是不可能的。

此外，不要忘记你的 Service 应该作为事务边界：每个方法都要用@Transactional注释标记。这也是它的另一个工作！

- David Lavender