一对一可不可以定义成一对多？

[货郎大叔]

在Entity Framework 6.0中，一对一可不可以定义成一对多，多的那一方，集合元素只有1个不就得了呗？

[货郎大叔]

引用 5 楼 以专业开发人员为伍 的回复:

比如说一个员工原本只能有一个离职，但是假设员工基本资料跟升迁离职系统是分开的，那么自然，员工基本信息系统跟离职升迁系统中的离职信息是“一对多”地关联的，后者具有外键。但是你必须补充上业务逻辑，不管是数据库系统还是应用系统上进行约束，才能“模拟一对一”关系。

EF中的真正意义上的"一对一"也没有要求额外用代码约束啊？

[ajijiij]

我认为是可以的，两者逻辑并没有太大的冲突

[货郎大叔]

EF中的"一对一"是不是有什么单向、双向之类的，很复杂吗？

[正怒月神]

单向，双向的说法。 只是看你在2个实体层，是不是都配置了对象的关联，是如何配置的（一对一，还是多对多）。 比如我在User和Address这两个model都配置了另一个对象的引用。 那么就是双向的， 如果我只在User配置了Address。那么就是单项的。

[以专业开发人员为伍]

引用 6 楼 货郎大叔 的回复:

EF中的真正意义上的"一对一"也没有要求额外用代码约束啊？

什么叫做“EF中真正意义上的一对一”呢？我发现你总是对自己进行“自相矛盾”式的悖论式的偷换逻辑因果关系。

[以专业开发人员为伍]

逻辑上当然要明确区别，才可能真正接受技术上的差异并且知道必须编写更多代码进行约束。

[qq_39080073]

当然不可以，老前辈定义下来的两个概念都是有区分的。监控摄像头

[圣殿骑士18]

当然可以。但是你看c#语法，搞出这么多语法是为了什么？不就是为了在最合适的场景，用最合适的特性，写出最优美稳健的代码吗。 当你对99分到100有了追求时，你就能理解各种各样的设计规则了。

[以专业开发人员为伍]

“EF上的真正意义上的一对一”这个说法的意思就是说连一对一也要分为我们的说的一对一是“假的”，谁说了都不算。lz 学习了“EF上的真正的一对一”才是经典，任何人真正理解和使用过的东西都不如书本上写的更真。这个逻辑就会一辈子都研究书本。

[以专业开发人员为伍]

EF没有什么“用一对多来模拟一对一”的约束机制，本来也不可能有。纠结“一对一没有约束”其实就是无关的东西。

“按照常识”，我们用A这个实践东西来强行模拟合同（规范）B，那么就要增加必要的约束来保证。这其实是从常识出发，真的不是——也不能——从书本上直接找到并不存在的、跟这里一摸一样的文字描述来描述约束。这就好像郑人买履，跑到家也找不到专门为自己的脚而单独发明的尺子。

[正怒月神]

可以！你把一对一，定义成一对多。是可以的。 理论上，无非就是 一对多时，获取多表的First()记录。 但是为什么要有，一对一，一对多，多对多？ 这是因为业务上决定怎么设计的。

[以专业开发人员为伍]

“多的那一方，集合元素只有1个”这实际上是你的业务逻辑，也就是你首先承认系统实现是“一对多”的，然后你要用业务逻辑来保证不会有超过1个对象存在，这一定要额外编程做到业务逻辑约束。

[以专业开发人员为伍]

比如说一个员工原本只能有一个离职，但是假设员工基本资料跟升迁离职系统是分开的，那么自然，员工基本信息系统跟离职升迁系统中的离职信息是“一对多”地关联的，后者具有外键。但是你必须补充上业务逻辑，不管是数据库系统还是应用系统上进行约束，才能“模拟一对一”关系。