4

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

4

3 回答 3

3

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

他使用 POCO 类来了解所有数据访问类。例如，当他将 LINQ-to-SQL 更改为 NHibernate 时，他需要做的就是更改过滤器中的“映射”，而他不必对业务逻辑进行任何更改。

于 2009-01-10T06:54:32.793 回答
3

如果您不使用中间类将前端与 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

希望有帮助。

于 2009-03-08T07:35:51.653 回答
2

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

我想说只要您坚持存储库模式本身，您就不会破坏任何主要的设计模式。我认为拥有2套classa是一个选择问题，尽管很糟糕，但仍然是一个选择。

于 2009-01-10T06:54:07.287 回答