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类的不同实例来清理它,但这实际上只是一个美化改进.
>将逻辑放在存储库类中,即AppointmentRepository.这种方法的两个优点是(a)在存储库和IoC框架上使用依赖注入的能力,以防您决定更改数据模型,以及(b)您坚持使用Single Responsibility Principle – 它实际上是有意义的方法是它的位置.
将它们放入存储库的主要缺点是：(a)它们可能正在复制与DataContext中已存在的非常相似的逻辑作为存储过程; (b)他们在交易管理方面有一种令人头疼的方法(如果你也用它们来保存); (c)当你开始有大量的自定义查询返回特定操作或报告的专门定制的DTO时,你可以选择为每个DTO创建一个存储库,或者创建一个主服务器.所有DTO的“实用程序”存储库或其中一些松散相关的组.两者最终都是一个相当糟糕的设计.
这些是权衡;只有你可以决定哪个更适合你自己的目的.
我肯定会建议不要使用扩展方法,因为扩展方法很难发现(你不能只输入方法并让Intellisense选择相关参考),当你有能力时它们根本就没有必要直接修改或扩展(通过部分)原始类.
我还建议不要延长预约课程;我们使用像Linq To sql这样的工具的原因之一是我们可以处理POCO实体,这些实体不需要知道它们来自何处.出于这个原因,我个人非常反对将实体类与它们的DataContext耦合 – 依赖应该只是单向的.
