MVC存储库模式：创建模型类

Question

Reviewing Conery's storefront, and I dont understand why he used Linqs auto-generated classes (ie Order class) and then he has another Order class defined that is not a partial class. WHen using repository pattern should one manually create the classes, and disregard Datacontext altogether?

Answer 1

Rob has answered on this question in one of his show.

He Using POCO classes to be aware from all dataaccess classes. For example when he change LINQ-to-SQL to NHibernate all he will need to do i change his "mappings" in his filters, and he will not have to make any changes in bussiness logic.

Answer 2

If you don't decouple your front end from the linq classes using an intermediary class, you can't control with the data context gets garbage collected. Typically with data context types of instances you want to rid of them as soon as you're done using them. Here's how you might want to do this with the linq to sql context:

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

With the "using" block, you're disposing of the instance of MYDataContext at the last "}". However, if you do this you'll get an error then trying to use "thing" because the data context instance is gone. If you don't dispose of the data context, it's left hanging around until it's eventually garbage collected.

If you introduce an intermediary class to decouple the linq to sql code from the calling app you can still get rid of your data context instance and return the same data (just in a different object):

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

Hope that helps.

Answer 3

He said in one of his recent videos he doesn't like the way LINQ to SQL does mapping. I agree though I think it is complete overkill.

I'd say you're not breaking any major design patterns as long as you're sticking to the repository pattern itself. I think it's a matter of choice to have 2 sets of classesa, allbeit a bad one, still a choice.