我通过一个实际的例子学习ASP.Net和Entity Framework 4。为了对此进行试用,我使用User
为Repair
发送设备的示例。他们在线创建帐户,添加一组Details
(地址,电话,传真等),并在线创建返回表单(RMA
)。
我正在努力的概念是将Details
分配给Returns
。 Return
有一组Details
,一组用于联系,投放和结算。这些可以是Detail
表的外键,如下所示。
问题是,如果User
在线编辑Details
,则会更新Details
上使用的Return
。这不是理想的行为。 Return
应使用创建时可用的Details
。
问题是,如何使实体框架创建新的Detail
对象,而不是更新现有的对象。也就是说,如果用户使用新的邮政编码更新Detail
23,则不会更改Detail
23,而是创建新的Detail
(即45)。已从Detail
移除User
23,并将新Detail
45添加到User
。虽然使用RMA
23的现有Detail
不受影响,但如果您查询RMA
,则会获得在创建时提供的详细信息。
如果在阅读此问题时,您认为该概念存在缺陷,而DB的设计应该不同(即将Detail
数据复制到RMA
表中的列,或者以复合形式添加Detail
表的关键,用于创建修订历史记录)。我也很高兴听到那些明智的话。
答案 0 :(得分:1)
如果您的复杂数据编辑规则超出了基本CRUD的范围,那么您实际上对实体框架有两种选择。
放弃简单的数据绑定,并将您的特殊处理构建到位于GUI和数据层(EF)之间的业务规则层中。
放弃瘦EF层的简单性,将特殊数据处理规则放入存储过程,然后将EF模型中的CRUD过程设置为您定义的存储过程。
无论哪种方式,您都在妥协,因为没有ORM,EF或其他,可以容纳“无代码”数据绑定和非平凡的CRUD处理。选择适合您项目的方法并获得最佳效果。有些人不能没有数据绑定,有些人不能忍受它。有些爱存储过程和其他人不喜欢它们。