我在我的 .net MVC 项目中使用实体框架作为 ORM。我已经实现了存储库模式（通用）来获取/保存/更新/删除 DAO（数据访问对象）。我也有包含所有业务逻辑的业务对象。例如，我有一个名为 Student 的 DAO 和一个名为 Student 的 BO（业务对象）。BO 包含逻辑，DAO 只是存储在 DB 中的数据。现在我想知道学生存储库是否应该返回业务对象而不是 DAO？我可以通过在从 Repository.Get() 返回之前将 DAO 转换为业务对象来使用 Automapper 来实现这一点。与所有其他方法相同。但这是一个好习惯吗？
更新
我有一个数据访问层项目和一个业务逻辑项目。实体框架在部分类中创建其实体（到数据访问项目中），因此我实际上可以使用其他部分类扩展实体，但问题是我在业务项目中引用了数据访问项目并且我无权访问数据访问项目中的逻辑代码。所以我必须将逻辑放在业务项目中，但由于不可能在两个项目上创建部分类，我必须采取另一种方式......或者你知道如何更好地构建和解决问题方法？
恕我直言，有几个目标（一些竞争）：
你能在没有数据库的情况下测试你的业务逻辑吗？可能是的，无论这些类是 EF POCO 实体还是从 DAO 映射。
您的域对象是否与您的域匹配？他们的名字选得好吗？它们是否始终处于有效状态？（这对于一堆公共读/写属性来说可能很困难。）领域驱动的设计考虑适用于此。（我不是这方面的专家。）
您能否放心地将 EF 换成 Dapper，将 SQL Server 换成 MongoDB，或者将当前数据访问换成 Web 服务调用，而无需更改数据访问层之外的任何内容？我的怀疑是否定的。通用存储库倾向于将 IQueryable 泄漏到其他层。并非所有东西都支持查询，而且提供者的实现也各不相同。单元测试通常使用 LINQ to Objects，它的行为与 LINQ to Entities 不同。此外，如果要提取 Web 服务合同，则必须查看所有类以查找所有查询。请参阅IQueryable 是紧耦合。
最后，你需要这一切吗？如果您的应用程序的目的是 CRUD 数据访问，并且在简单验证之上没有业务逻辑，则可能不是。这些考虑绝对适用于复杂的应用程序或站点。
是的，这完全是一个好习惯。通常，您在域程序集中定义了存储库接口。这些接口由域服务使用，并在持久性组装中实现。Entity Framework 允许您流畅地映射业务实体，而不会用属性污染它们或强制它们从某些特定的基类（POCO 实体）继承。这使您的域模型 Persistence Ignorant。