Question

我在Java中使用REST API，该应用程序有三层：

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

现在，我意识到＆＃34;服务＆＃34;没有多少工作要做，一部分发回和转发请求。然后我意识到这是因为＆＃34; Dao＆＃34;和＆＃34;服务＆＃34;有相同的界面。

所以，我改变了：

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

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

然而，现在我意识到＆＃34; jsonModel＆＃34;对象有更多的信息，而不仅仅是要保存的信息。例如，有用于访问我的API的用户名和密码。这是控制器的责任。也许我已经向＆＃34;服务＆＃34;发送了许多信息。我想。

所以，我改变如下：

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

但在那之后我意识到现在我有三个不同的对象，这意味着我必须做两个不同的映射。很多代码看起来都是过度设计的。

我现在如何改变，让它简单实用？

Answer 1

您的中间选项很好，但我有一个特定的Info型号，不会被您的应用用户名和密码污染。

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

通常可以避免三豆。过去两个对我来说效果最好 - 恰好是这个阵容。

另一种方法是在每一层使用相同的 bean。但我讨厌那个。
你最终会得到一个包含hibernate注释，JSON注释，验证注释，多个构造函数，不同情况的不同日期格式等的Info bean。一团糟。
我只提到它，因为网上有许多例子提倡它，并且在很多书中使用过。但是，只有当您的数据库，用户界面和业务表示恰好完全相同时才能真正起作用 - 在现实世界中，它永远不会。

此外，不要忘记您的Service应该充当您的交易边界：每个方法都注明@Transactional：这是另一项工作！

如何组织控制器，服务和道

1 个答案: