.net – 将Linq中的外键设置为SQL
众所周知,如果已经加载了实体,则无法直接在Linq to SQL中设置外键ID.但是,您可以通过它的外键查找实体,然后使用实体关系将实体设置为外部实体. (我在这里取出了枚举,并使用整数值来简化).即如果我有一个加载的约会实体和一个相关的AppoinmentStatus实体,我不能这样做: – ExistingAppointment.AppointmentStatusID = 7 但我可以这样做: – ExistingAppointment.AppointmentStatus = (From appstat In db.AppointmentStatus _ Where appstat.StatusID = 7 _ Select appstat).Single 我有这样的东西乱扔我的代码,我想重构.所以… 我显然可以在这样的模块中使用辅助方法: – Module Helper Public Shared Function GetAppointmentStatus(ByVal AppStatusID As Integer) As AppointmentStatus GetAppointmentStatus = (From appstat In db.AppointmentStatus _ Where appstat.AppointmentStatusID = AppStatus _ Select appstat).Single End Function End Module 我甚至可以把它变成一个扩展方法,就像这样. Imports System.Runtime.CompilerServices Module Helper Extension()> _ Public Shared Function GetAppointmentStatus(ByVal db as DataClassesDataContext,ByVal AppStatusID As Integer) As AppointmentStatus GetAppointmentStatus = (From appstat In db.AppointmentStatus _ Where appstat.AppointmentStatusID = AppStatusID _ Select appstat).Single End Function End Module 我也可以将它放在Linq to SQL分部类中,就像这样. Partial Public Class DataClassesDataContext Public Function GetAppointmentStatus(ByVal AppStatusID As Integer) As AppointmentStatus GetAppointmentStatus = (From appstat In Me.AppointmentStatus _ Where appstat.AppointmentStatusID = AppStatusID _ Select appstat).Single End Function End Class 此外,我可以将代码放在Linq to SQL Appointment Entity分部类中,如下所示: – Partial Public Class Appointment Public Function GetAppointmentStatus(ByVal db as DataClassesDataContext,ByVal AppStatusID As Integer) As AppointmentStatus GetAppointmentStatus = (From appstat In db.AppointmentStatus _ Where appstat.AppointmentStatusID = AppStatusID _ Select appstat).Single End Function End Class 我应该做什么,为什么,还是有更好的选择? 解决方法这有两个主要的思想流派:>将逻辑放在DataContext中(如果您手动编写DataContext,则为部分类或实际类).这背后的基本原理是你的DataContext已经知道你所有不同的实体,所以这不会产生任何额外的耦合,也不会导致类膨胀. 当然,缺点是,如果你有几百个这样的API方法(最终你可能会),那么你的DataContext将很快变成泥球,充满了任何程序员决定抛出的随机查询API您可以尝试通过将相关函数分离到同一部分DataContext类的不同实例来清理它,但这实际上只是一个美化改进. 将它们放入存储库的主要缺点是:(a)它们可能正在复制与DataContext中已存在的非常相似的逻辑作为存储过程; (b)他们在交易管理方面有一种令人头疼的方法(如果你也用它们来保存); (c)当你开始有大量的自定义查询返回特定操作或报告的专门定制的DTO时,你可以选择为每个DTO创建一个存储库,或者创建一个主服务器.所有DTO的“实用程序”存储库或其中一些松散相关的组.两者最终都是一个相当糟糕的设计. 这些是权衡;只有你可以决定哪个更适合你自己的目的. 我肯定会建议不要使用扩展方法,因为扩展方法很难发现(你不能只输入方法并让Intellisense选择相关参考),当你有能力时它们根本就没有必要直接修改或扩展(通过部分)原始类. 我还建议不要延长预约课程;我们使用像Linq To SQL这样的工具的原因之一是我们可以处理POCO实体,这些实体不需要知道它们来自何处.出于这个原因,我个人非常反对将实体类与它们的DataContext耦合 – 依赖应该只是单向的. (编辑:威海站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |