I found that whether the Strong-typed TableAdapter，or LINQ or EF……Microsoft is always fixing the CRUD methods with model classes together……Why don't create layer cs files so as to seperate CRUD methods from model classes together in different namespaces？That'd
be OK and easy for Microsoft……
PS：This isn't a question about real EF or LINQ or a ADO.NET，What I'm intersted in is Why they are designed like this？SO THIS IS A DESIGNING QUESTIO，PLEASE DON'T MOVE THE THREAD TO ADO.NET, LINQ OR EF PART！
I mean when you use LINQ, EF or TableAdapter... When you see the auto-generated codes, you will find that model classes are always mixed with CRUD mtthods. If you are using EF, you can see codes like this:
using (XXXEntityContext efc = new XXXEntityContext())
{
efc.XXXs.AddXXX(instancehere....);
}
Don't you see Insert, delete, as well as update things come from XXXEntitContext, but the model class comes from this same Namespace,too...
I think it's better to seperate them from each other.
Why don't create layer cs files so as to seperate CRUD methods from model classes together in different namespaces
Yep I understand your question and I am not sure exactly why the auto-generated classes are not separated as you ask. Logically if we were building our own application we would probably do this and separate the methods possible into even different layers.
However the beauty of a technology like EF is not having to concern ourselves too deeply with what is happening under the covers so long as it works (and move on to coding what is most important: typically the domain or business logic). I think the best folks
that could provide insight into why the EF classes are designed the way they are is someone on the EF or ADO.NET team at MSFT. You can take a look at their blog below and possibly get the answer direct from those that helped design it.
TimoYang
Contributor
3732 Points
1275 Posts
Why does Microsoft combine the logic methods with Model classes together？
Jan 02, 2012 02:57 AM|LINK
I found that whether the Strong-typed TableAdapter，or LINQ or EF……Microsoft is always fixing the CRUD methods with model classes together……Why don't create layer cs files so as to seperate CRUD methods from model classes together in different namespaces？That'd be OK and easy for Microsoft……
PS：This isn't a question about real EF or LINQ or a ADO.NET，What I'm intersted in is Why they are designed like this？SO THIS IS A DESIGNING QUESTIO，PLEASE DON'T MOVE THE THREAD TO ADO.NET, LINQ OR EF PART！
Mikesdotnett...
All-Star
155645 Points
19985 Posts
Moderator
MVP
Re: Why does Microsoft combine the logic methods with Model classes together？
Jan 02, 2012 07:20 AM|LINK
Are you talking about tutorials? Or what?
There's nothing to stop you doing this yourself if that's how you like to organise your app.
Web Pages CMS | My Site | Twitter
TimoYang
Contributor
3732 Points
1275 Posts
Re: Why does Microsoft combine the logic methods with Model classes together？
Jan 02, 2012 08:06 AM|LINK
Hello again,
I mean when you use LINQ, EF or TableAdapter... When you see the auto-generated codes, you will find that model classes are always mixed with CRUD mtthods. If you are using EF, you can see codes like this:
using (XXXEntityContext efc = new XXXEntityContext())
{
efc.XXXs.AddXXX(instancehere....);
}
Don't you see Insert, delete, as well as update things come from XXXEntitContext, but the model class comes from this same Namespace,too...
I think it's better to seperate them from each other.
atconway
All-Star
16846 Points
2756 Posts
Re: Why does Microsoft combine the logic methods with Model classes together？
Jan 09, 2012 01:55 PM|LINK
Yep I understand your question and I am not sure exactly why the auto-generated classes are not separated as you ask. Logically if we were building our own application we would probably do this and separate the methods possible into even different layers. However the beauty of a technology like EF is not having to concern ourselves too deeply with what is happening under the covers so long as it works (and move on to coding what is most important: typically the domain or business logic). I think the best folks that could provide insight into why the EF classes are designed the way they are is someone on the EF or ADO.NET team at MSFT. You can take a look at their blog below and possibly get the answer direct from those that helped design it.
ADO.NET team blog:
http://blogs.msdn.com/b/adonet/
TimoYang
Contributor
3732 Points
1275 Posts
Re: Why does Microsoft combine the logic methods with Model classes together？
Jan 10, 2012 02:12 AM|LINK
Hello atconway,
So you mean that it's a GENERAL IDEA AND DESIGN? And we can still add up something to it when we need... And MS wants to make us "most flexible"???