2
我目前正在使用使用以下技术的项目。更新对象图时实体框架的断开行为
- ASP.net MVC - 表现层
- 数据服务层 - （WCF）
- 数据传输对象（DTO）与自动映射图层
- 领域层（POCO，代码第一次实体框架）
- 存储库层+实体框架4.3 + DbContext。
我们使用DTO将域对象反过来转换为使用自动映射器并通过使用WCF服务发送到前端。
另外，我们在WCF层为每个请求创建每个基于请求的DBContext，并且我们的WCF服务上下文由客户端DTO中的Per Call和No Tracking启用构建，并且完全断开连接。
另外我们有以下对象图。
public class User : BaseEntity
{
public virtual Identity Identity { get; set; }
public string UserName { get; set; }
public string Password { get; set; }
public int IdentityId { get; set; }
public virtual IList<Group> Groups{ get; set; }
}
public class Identity : BaseEntity
{
public string FirstName { get; set; }
public string LastName { get; set; }
public virtual IList<Email> Emails { get; set; }
public virtual IList<PhoneNumber> PhoneNumbers { get; set; }
}
我们的Dto结构与Domain相比更像。
我的问题：
当涉及到更新对象图，例如：UpdateUser两个（用户用户）;实体框架的最佳方法是什么？
现在我们使用单一功能来保存导航数据例如：UpdateEmail（userId，Email）（仅保存原始数据而非关系）;所以当我们考虑一个UnitOfWork时，它会在数据库中进行大量的插入和更新。
当前实现如下
public void UpdateUser(User user)
{
UpdateEmail(user.userId, user.Idenity.Emails);
UpdatePhone(user.userId, user.Identity.PhoneNumbers);
etc.............
UpdateUser(user);
UnitOfWork.Commit();// Calling DbContext.SaveChanges();
}
有，我们可以在上述情况与实体框架使用与断开连接的对象图中的任何模式或最佳实践？
非常好是您的问题，现在你使用EF，它会提供更多的电话号码？由于您的电话号码和电子邮件是单独的表格，因此我无法在此找到解决办法。您可以为用户创建一个扁平化的实体，其中包含每个实体的五个并映射到插入的proc。它会减少呼叫，但不是最干净的恕我直言。如果您一次处理多个用户，那么可能会分解UOW以仅为每个用户执行操作，这样您的交易就会更短。目前是否存在性能问题或仅仅是未来的问题？ –
现在我们没有太多性能问题。但是，由于许多更新都发生在同一个函数中，所以存在一些锁定问题。奉承不是一种选择，因为我们正在将其作为域驱动设计。 – marvelTracker
添加下面作为建议的答案与反馈。 –