将 DAO 注入实体是一件坏事吗? [英] Is injecting DAO into entities a bad thing?

问题描述

因此，像大多数新的 .NET 开发人员一样，您开始到处传递数据集，尽管事情可以完成工作，但似乎并不正确.

So like most new .NET developers you start of passing DataSets everywhere and although things do the job it doesn't seem right.

下一步通常是创建扩展 DAL 基类的实体对象，例如

The next progression is usually to create entity objects that extend a DAL base class so you have i.e.

public class User : UserDAL
{
    //User specific methods
}
public class UserDAL
{
  //Bunch of user specific properties
  public User Load(int Id)
  {
    //Some low level ADO calls
  }
  private User LoadFromDataSet(DataSet ds)
  {
     //Load entity properties from DataSet 
  }    
}

用户使用 ADO.NET 扩展具有低级别数据访问调用的 UserDAL 对象.

User extends UserDAL objects that has low level data access calls using ADO.NET.

从这里您继续了解到，此实现意味着您绑定到数据访问层，并且您可以使用单独的实体、数据访问对象和 DAO 接口进行模拟或在需要时轻松换出 DAO.即

From here you go on to learn that this implementation means your tied to a data access layer and you make use of a separate entity, data access object and DAO interface for mocking or to easily swap out the DAO if need be. i.e.

public UserDAO : IUserDAO
{
  //Data access Functions
}

通过使用泛型和反射或一个好的 ORM，您可以减轻一些更常见的数据访问 CRUD 操作，即

With use of generics and reflection or a good ORM you can relieve some of the more common data access CRUD operations i.e.

Public UserDAO<User> : BaseDAO<User>, IUserDAO
{
  //BaseDAO deals with basic crud so more custom data access methods can go here 
}

所以基本上这就是我目前所处的位置，除了一些其他好的实践，比如使用 IoC 来解决我想要的特定 IUserDAO.但是虽然我看到了这种结构的优势，但我也觉得我错过了旧的 User.Load(1) 方法调用.

So basically that's where I am currently at, aside from some other nice practices like using IoC to resolve the specific IUserDAO I want. But while I see the advantage to this structure I am also left feeling like I miss the old User.Load(1) method calls.

我想知道的是，将我的 IUserDAO 注入 User 实体并让其处理基本的 CRUD 操作会不会是一件坏事?

What I was wondering is would it be such a bad thing to inject my IUserDAO into the User entity and have that take care of the basic CRUD operations?

我的理解是，作为 POCO，用户实体不会有问题通过网络传递，并且添加 Save()、Load() 等方法在数据传输对象的意义上没有相关性.

My understanding is that as a POCO the User entity would have no problems been passed over the wire and adding methods like Save(), Load() etc would have no relavence in the sense of a data transfer object.

但话虽如此，我的实体通常具有延迟加载的集合，这在 DTO 意义上没有任何意义.此外，我相信使用 WFP 可以选择我想要序列化的属性，或者至少我可以在需要通过网络发送时创建一个新的 UserDTO.

But with that said my entities usually have lazy loaded collections which mean nothing in a DTO sense. Also, with WFP I believe can pick and chose which properties I want serializing, or at very least I could create a new UserDTO when I need to send it across the wire.

所以基本上，除了这个问题之外，让我的用户实体包含与 DataAccess 相关的方法还有哪些其他问题?也有人可以澄清我所说的是否被称为活动记录模式还是其他什么?

So basically, aside from that issue what are the other problems with making my User entity include DataAccess related methods? Also could someone clarify whether what I am talking about is referred to as an active record pattern or is this something else?

克里斯蒂安利巴尔多指出:

cristianlibardo noted:

至于潜在的缺点，与持久性代码、跟踪/更新关联、可测试性和查询时的驻留有更大的耦合.

As for potential drawbacks there is greater coupling to peristence code, resitence when following/updating associations, testability and querying.

某种程度的耦合会更高，但我的想法是这样的:

There would be a greater some level of coupling but what I was thinking was somehting like the following:

public class User
{
   IUserDAO userDAO;
   public User()
   {
         userDAO = IoCContainer.Resolve<IUserDAO>;
   }
  public User(IUserDAO userDAO)
   {
         this.userDAO = userDAO;
   }
   //DAL methods
}

所以耦合应该是最小的，至于可测试性，我不认为这是一个问题，因为我可以将一个模拟 DAO 注入实体.

So the coupling should be minimal and as for testability, I don't see it as a problem as I can just inject a mock DAO into the entity.

感谢 Brian Hasden，这些都是非常好的资源，但我想我只是想为我显然要做的事情辩护.感谢您提供上述理由.

Thanks to Brian Hasden, these are really good resources, but I guess I just wanted justification for something I was obviously going to do. Thanks for giving the said justification.

推荐答案

我得出了同样的结论.加载在实体中通常没有意义，因为一旦您有了一个实例，您要么正在创建一个新实体，要么已经有了一个已加载的实体.多年来，我一直在使用带有保存(创建和更新)和删除的实体，没有任何问题.话虽如此，仍然有一个 DAO 来做其他事情通常很有用，所以你并没有完全将 DAO 和实体结合起来.大多数时候，我的实体的 Save 和 Delete 方法只是调用 DAO 的 Save 和 Delete 方法.

I came to the same conclusion. The load usually doesn't make sense in the entity because once you have an instance, you're either creating a new entity or you've already got a loaded entity. I've been using entities with Save (create and update) and Delete for years now without any issues. That being said, it's usually useful to still have a DAO to do other things, so you're not exactly combining the DAO and the entity. Most of the time for my entities the Save and Delete methods are just calling into the DAO Save and Delete methods.

顺便说一句，我通常将脏标志与实体结合起来，以了解属性何时发生更改，这样您就不会在实体未更改时进行不必要的调用来保存.

BTW, I usually combine a dirty flag with the entity to know when properties have been changed so that you don't make unnecessary calls to save when the entity hasn't changed.

通常情况下，除了包含私有成员的 getter 和 setter 之外，什么都不做的实体意味着您正在使用一个贫血的域模型.这是一种颇受争议的反模式.

Typically, entities that don't really do anything but contain getters and setters for private members mean you're working with an anemic domain model. It's an anti-pattern that's fairly controversial.

您可以在以下位置找到更多信息:

You can find more information about it at:

http://www.martinfowler.com/bliki/AnemicDomainModel.htmlhttp://wrschneider.blogspot.com/2005/01/avoiding-anemic-domain-models-with.htmlhttp://www.dotnetjunkies.com/WebLog/理查德斯莱德/档案/2007/03/07/209401.aspx

这篇关于将 DAO 注入实体是一件坏事吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！