被注入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的用户实体将不会有任何问题已经越过电线像保存添加方法（），负载（）等将有一个数据传输对象的意义上的relavence。

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感。此外，世界粮食计划署相信可以从中选择哪些属性我想序列化，或者最起码我可以创建一个新的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.

因此​​，基本上，从这个问题抛开什么其他问题，让我的用户的实体包括数据访问相关的方法？也可能有人澄清，究竟是什么，我说的是被称为活动记录模式或者这是什么东西？

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注意：

cristianlibardo noted:

至于潜在的缺点如下/更新的关联，可测试性和查询的时候有更大的耦合peristence code，resitence。

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和实体你没有完全的完美组合。大多数时候，我的实体保存和删除方法只是调用到DAO保存和删除的方法。

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.html http://wrschneider.blogspot.com/2005/01 /avoiding-anemic-domain-models-with.html 的http://www.dotnetjunkies.com/WebLog/richardslade/archive/2007/03/07/209401.aspx

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