【发布时间】：2011-07-13 01:30:56
【问题描述】：
因此，像大多数新的 .NET 开发人员一样，您开始在各处传递 DataSet，尽管事情做得很好，但似乎并不正确。
下一个进展通常是创建扩展 DAL 基类的实体对象，以便您拥有即
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
}
}
User 使用 ADO.NET 扩展具有低级数据访问调用的 UserDAL 对象。
从这里您将继续了解此实现意味着您与数据访问层绑定，并且您使用单独的实体、数据访问对象和 DAO 接口进行模拟或在需要时轻松更换 DAO。即
public UserDAO : IUserDAO
{
//Data access Functions
}
通过使用泛型和反射或良好的 ORM，您可以减轻一些更常见的数据访问 CRUD 操作，即
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) 方法调用。
我想知道的是，将我的 IUserDAO 注入到 User 实体中并让它处理基本的 CRUD 操作会是一件坏事吗？
我的理解是，作为 POCO，用户实体通过网络传递不会有任何问题，并且添加 Save()、Load() 等方法在数据传输对象的意义上没有相关性。
但话虽如此，我的实体通常具有延迟加载的集合，这在 DTO 意义上没有任何意义。此外，我相信使用 WFP 可以挑选我想要序列化的属性，或者至少我可以在需要通过网络发送它时创建一个新的 UserDTO。
所以基本上，除了那个问题之外，让我的用户实体包含 DataAccess 相关方法的其他问题是什么？也有人可以澄清一下我所说的是否被称为活动记录模式还是其他什么？
编辑：
克里斯蒂安利巴多指出：
至于潜在的缺点，与持久性代码、跟踪/更新关联时的重新定位、可测试性和查询有更大的耦合。
会有更大程度的耦合，但我的想法是这样的：
public class User
{
IUserDAO userDAO;
public User()
{
userDAO = IoCContainer.Resolve<IUserDAO>;
}
public User(IUserDAO userDAO)
{
this.userDAO = userDAO;
}
//DAL methods
}
所以耦合应该是最小的，至于可测试性，我不认为这是一个问题，因为我可以将一个模拟 DAO 注入到实体中。
感谢 Brian Hasden，这些资源非常好，但我想我只是想为我显然要做的事情找理由。感谢您提供上述理由。
【问题讨论】：
标签： .net architecture