2
  • 你手里有一个“方法”。
  • 它击中了 Db。
  • 根据方法的实现，它可能是加载、保存、删除一些实体。

你需要把这个方法放在某个地方；您的选择是存储库或业务逻辑。

问题： 此方法的哪些属性使其成为业务逻辑的一部分，以便您将其放置在业务逻辑层中？

如果我换个说法：你如何决定一个方法应该放在“业务逻辑”还是“存储库”？

4

3 回答 3

4

您的存储库应该只执行简单的 CRUD 操作（例如插入、选择、删除等）。如果它做得更多，它属于业务逻辑。

您可以有一个服务层来执行业务逻辑，然后调用您的存储库，但您的存储库应该是“愚蠢的”，只做 CRUD。

于 2013-01-08T14:41:54.587 回答
1
  • 它击中了 Db。

如果该方法访问数据库，无论是执行 SQL、从 O/R 映射器查询还是任何直接与持久性相关的东西，它都应该在持久层中，而不是在业务层中。

它可能在一个 Repository 实现中，一个 DAO，你可以命名它，但绝对是一个数据访问层类。

于 2013-01-08T15:50:54.843 回答
0

我更喜欢将存储库调用作为基本的 CRUD 操作

具有业务逻辑的代码将在 b.logic 层。该层可以使用 Repo 调用来实现它所追求的目标

一个更好的方法，我适合的是将其视为 3 层

工作流或事务脚本层 业务逻辑层 存储库层

Repo 调用之间的工作流协调并将数据传递给业务逻辑层以执行其任务

于 2013-01-09T09:12:30.110 回答