在 Linq to 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

我应该做什么，为什么，或者有更好的选择吗？

对此有两种主要的思想流派：

1. 将逻辑放入DataContext（部分类，或者实际类，如果你编码的话DataContext用手）。这背后的理由是你的DataContext已经了解所有不同的实体，因此这不会创建任何额外的耦合，也不会导致类膨胀。

   当然，缺点是，如果您有几百个这样的 API 方法（并且您最终可能会这样做），那么您的DataContext很快就会开始变成一团泥球，里面充满了任何程序员决定投入的每个随机查询 API。您可以尝试通过将相关函数分离到同一部分的不同实例中来清理它DataContext类，但这实际上只是表面上的改进。

2. 将逻辑放入存储库类中，即AppointmentRepository。这种方法的两个优点是（a）能够在存储库和 IoC 框架上使用依赖项注入，以防您决定更改数据模型，以及（b）您坚持使用单一责任原则- 它实际上使sense让方法就在它所在的地方。

   将它们放入存储库的主要缺点是： (a) 它们可能会重复您的存储库中已经存在的非常相似的逻辑。DataContext作为存储过程； (b) 当涉及到事务管理时，它们有一种令人头痛的方式（如果你也使用它们来保存）； (c) 当您开始有大量自定义查询，这些查询返回针对特定操作或报告专门定制的 DTO 时，您只剩下两个糟糕的选择：为每个 DTO 创建一个存储库，或者创建一个主数据库所有 DTO 或其中一些松散相关组的“实用程序”存储库。两者最终都是一个相当糟糕的设计。

这些就是权衡；只有您可以决定哪个更适合您自己的目的。

I would绝对建议against扩展方法方法，因为扩展方法很难发现（您不能只键入方法并让 Intellisense 选取相关参考），并且当您有能力直接修改或扩展时，它们也根本没有必要（通过部分）原始类。

我还建议不要延长Appointment班级;我们使用 Linq To SQL 等工具的原因之一是我们可以处理 POCO 实体don't需要知道他们来自哪里。出于这个原因，我个人非常反对实体类与它们的耦合DataContext- 依赖关系应该只是单向的。