MVC仓库模式：创建模型类

Question

审查Conery的店面，我不明白他为什么使用Linqs自动生成的类（即Order类），然后他有另一个定义的类不是部分类。什么时候使用存储库模式应该手动创建类，并完全忽略Datacontext？

Answer 1

如果你没有使用中间类来分离你的前端和linq类，那么你就无法控制数据上下文被垃圾收集。通常情况下，只要您完成了使用它们，您想立即删除它们的实例的数据上下文类型。这里是你会如何想用LINQ to SQL的情况下做到这一点：

using (MyDataContext data = new MyDataContext()) 
{ 
    SomeThing thing = data.Things(t => t.ID == 1); 
    return thing; 
} 
... the MyDataContext instance is gone 

随着“使用”块，你处置MYDataContext在最后的“}”的实例。但是，如果你这样做，你会得到一个错误，然后尝试使用“东西”，因为数据上下文实例已经消失。如果你不要处理数据上下文，它会一直挂起，直到它最终被垃圾收集。

如果你介绍的中介类从你仍然可以摆脱你的数据上下文实例调用应用解耦的LINQ to SQL代码，并返回相同的数据（只是在不同的对象）：

using (MyDataContext data = new MyDataContext()) 
{ 
    SomeThing thing = data.Things(t => t.ID == 1); 
    SometThingElse otherThing = ConvertSomethingToSomethingElse(thing); 
    return otherThing; 
} 
... the MyDataContext instance is gone 

希望有所帮助。

Answer 2

他在他最近的一个视频中说他不喜欢LINQ to SQL映射的方式。我同意，但我认为这是完全矫枉过正。

我想说，只要你坚持存储库模式本身，你不会破坏任何主要的设计模式。我认为有两组classa是可以选择的，尽管它们是不好的，但仍然是一个选择。

Answer 3

Rob在他的一个节目中回答了这个问题。

他使用POCO类从所有数据访问类中获知。例如，当他将LINQ-to-SQL更改为NHibernate时，他将需要在他的过滤器中更改他的“映射”，并且他不需要对商务逻辑进行任何更改。