>Whatever ORM fits the situation. There's no reason to be writing core ADO.NET methods with the technologies available today. See this blog post: http://lostechies.com/jimmybogard/2012/07/24/dont-write-your-own-orm/

Interesting articles - also
http://lostechies.com/jimmybogard/2012/07/20/choosing-an-orm-strategy/
http://lostechies.com/jimmybogard/2012/07/26/orm-techniques-for-legacy-databases/

For Dimitris and my wish a typical case of yes and no ;-)
If you look at it from one side: wishing for DB exchangeability and change tracking really are solved at ORM level.

My wish to have: local disk/SQL usage as caching and munging platform. On widows boxes could be done via linked servers of SQL Express. POOP ORM afficionados will probably shudder at the thought ;-) But SQL Express on phones or non-Windows platfoms ? Now me shuddering at the first thought and "not likely" for the second.

DAtamunging via micro ORM as in choosing article: doable, but which way is more elegant is a matter of taste and expirience IMO. IN the table/row arena SQL is still king for me if I have the data accessible by *one* dialect.

I want the "lightweight local SQL cache and munging" which is NOT offered by ADO.Net by disregarding to use the local disk and concentrating only on RAM as query target. Sounds a lot like vfp characteristic, but that is what you asked for ;-)

regards

thomas