标签：end entity 时间 一对一 优雅 alt leo mail 最大
在这两天的时间已经有两位同事问到EF（Code First）如何配置一对一的关系，这个说难也不难，说简单吧，一旦设计跑偏那么在Coding的过程中将会很痛苦。
先举个很简单的例子，两个类User和Profile，User里面存在用户的基本信息比如邮箱和密码，Profile里面存放用户的个人资料。
public class User
{
public int Id { get; set; }
public string Email { get; set; }
public string Password { get; set; }
public virtual Profile Profile { get; set; }
}
public class Profile
{
public int Id { get; set; }
public string Name { get; set; }
public Gender Gender { get; set; }
public string Phone { get; set; }
public string Address { get; set; }
public virtual User User { get; set; }
}
上面的代码应该是直接了当的。透过领域模型应该能充分描述出User和Profile的业务。分析：对于一个User来说只能有一个Profile（一对一），反过来对于一个Profile来说只能对应一个User（一对一），而且也必须有一个User。下面是通过fluent api做一些映射
public class UserMapping : EntityTypeConfiguration<User>
{
public UserMapping()
{
ToTable("tb_User");
}
}
public class ProfileMapping : EntityTypeConfiguration<Profile>
{
public ProfileMapping()
{
ToTable("tb_Profile");
HasKey(u => u.Id)
.HasRequired(u => u.User) // 对于一个Profile来说必须有一个User否则Profile无家可归
.WithOptional(u => u.Profile) // 同事一个User对应一个Profile 非必须
.WillCascadeOnDelete(false); // 不需要级联删除
}
}
上面的代码也应该也是直接了当的。那么这样生成的数据库结构是什么样的呢？约束又是什么样的呢？又是否符合我们的业务需求
User表没有什么问题，Profile的ID字段不单单是一个主键，同时也是一个外键。我们回到具体的业务中来。当我插入一条User数据的时候要不要插入Profile数据呢？其实是都可以的，如果同时插入的话，User和Profile应该是一起往前走的，而且User的ID和Profile的ID是一样的。那如果插入User的时候不插入Profile呢，其实也没有问题，详细的说明：
假如我插入两条User数据，User表会有两条数据，ID分别为1和2。Profile表为空，没有数据。2用户有一天回过头来想完善自己的个人详细信息，插进去的Profile数据ID应该为2，后来1用户也来完善自己的个人资料，这个时候插入的Profile数据ID为1（虽然2用户先完善的，2用户的ProfileID还是2,1用户的ProfileID还是1）。
static void Main(string[] args)
{
DemoDbContext db = new DemoDbContext();
var user = db.Users.SingleOrDefault(u => u.Id == 2);
Profile profile = new Profile
{
Address = "beijing"
};
user.Profile = profile;
db.SaveChanges();
}
顺便对领域模型唠叨几句：
领域模型是领域驱动设计中最重要的对象，它们是描述我们业务的对象，应该最大力度保持干净，整洁。作为一名开发人员应该多花点时间放在领域的设计上。然而领域的设计应该是和领域专家（产品经理）强度沟通的情况下去完成设计的。比如要做一款财务软件，程序员怎么可能对财务非常精通，都是和财务专家或懂财务的人沟通的基础上去完成我们的领域设计。所以在公司中应确保最好，最有经验的开发人员分配到领域相关的任务上去。
标签：end entity 时间 一对一 优雅 alt leo mail 最大
原文地址：http://www.cnblogs.com/bidianqing/p/7512992.html
