Why does Microsoft combine the logic methods with Model classes together？

I found that whether the Strong-typed TableAdapteror LINQ or EFMicrosoft is always fixing the CRUD methods with model classes togetherWhy don't create layer cs files so as to seperate CRUD methods from model classes together in different namespacesThat'd be OK and easy for Microsoft

PSThis isn't a question about real EF or LINQ or a ADO.NETWhat I'm intersted in is Why they are designed like thisSO THIS IS A DESIGNING QUESTIOPLEASE DON'T MOVE THE THREAD TO ADO.NET, LINQ OR EF PART

Re: Why does Microsoft combine the logic methods with Model classes together？

TimoYang
Microsoft is always fixing the CRUD methods with model classes together

Are you talking about tutorials? Or what?

TimoYang
Why don't create layer cs files so as to seperate CRUD methods from model classes together in different namespaces

There's nothing to stop you doing this yourself if that's how you like to organise your app.

Re: Why does Microsoft combine the logic methods with Model classes together？

Mikesdotnetting
Are you talking about tutorials? Or what?

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.

Re: Why does Microsoft combine the logic methods with Model classes together？

TimoYang
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.

ADO.NET team blog:
http://blogs.msdn.com/b/adonet/

Re: Why does Microsoft combine the logic methods with Model classes together？

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"???