存储库模式以及业务对象和数据访问对象之间的映射

Question

我在我的 .net MVC 项目中使用实体框架作为 ORM。我已经实现了存储库模式（通用）来获取/保存/更新/删除 DAO（数据访问对象）。我还有包含所有业务逻辑的业务对象。例如，我有一个名为 Student 的 DAO 和一个名为 Student 的 BO（业务对象）。BO 包含逻辑，DAO 只是存储在 DB 中的数据。现在我想知道 Student-Repository 是否应该返回 Business-Object 而不是 DAO？我可以通过在从 Repository.Get() 返回 DAO 之前将 DAO 转换为业务对象来使用 Automapper 实现这一点。与所有其他方法相同。但这是一个好习惯吗？

更新

我有一个数据访问层项目和一个业务逻辑项目。实体框架在部分类中创建其实体（进入数据访问项目），因此我实际上可以使用其他部分类扩展实体，但问题是我在我的业务项目中引用了数据访问项目，而我无权访问数据访问项目中的逻辑代码。因此，我必须将逻辑放在 Business 项目中，但由于无法在两个项目上创建部分类，我必须另辟蹊径……或者您是否知道如何更好地构建和解决问题？道路？

Answer 1

恕我直言，有几个目标（一些竞争）：

• 使业务逻辑可独立测试
• 设计域对象以匹配您的域
• 将数据访问与其他一切分离
• 把事情简单化

你能在没有数据库的情况下测试你的业务逻辑吗？可能是的，无论类是 EF POCO 实体还是从 DAO 映射。

您的域对象与您的域匹配吗？他们的名字选得好吗？它们是否始终处于有效状态？（这对于一堆公共读/写属性来说可能很困难。）领域驱动的设计考虑在这里适用。（我不是这方面的专家。）

您能否将 EF 替换为 Dapper，将 SQL Server 替换为 MongoDB，或者将当前数据访问替换为 Web 服务调用，而无需更改数据访问层之外的任何内容 - 充满信心？我的怀疑是否定的。通用存储库倾向于将 IQueryable 泄漏到其他层。并非所有东西都支持查询，并且提供程序的实现各不相同。单元测试通常使用LINQ到对象，这并没有表现一样LINQ到实体。此外，如果要提取 Web 服务合同，则必须查看所有类以查找所有查询。请参阅IQueryable 是紧耦合。

最后，您需要所有这些吗？如果您的应用程序的目的是在简单验证之上没有业务逻辑的 CRUD 数据访问，也许不是。这些注意事项绝对适用于复杂的应用程序或站点。