O/R Mapper
http://blogs.msdn.com/aconrad/archive/2005/03/16/396999.aspx
Andrew war beim ObjectSpaces Team, zuviel zu seinem Hintergrund. Das Beschriebene ist in der Tat das Kernproblem von O/R Mapping für mich. An der Oberfläche ist die Idee großartig: ich muss keinen Data Access Code mehr schreiben und kann einfach Objekte (C# Klassen) instanzieren und persistieren. Aber wenn ich das konsequent für eine Applikation durchführen würde, dann wäre sie wahrscheinlich schlecht: 10 bis 100x zu hoher Memory Verbrauch und 10 bis 100x langsamer als nötig. Für einfache System (=wenige, kleine Objekte, Single-User Systeme) mag das hinkommen. Für große Systeme und da zähle ich auch NMC zu (=viele, teilweise große Objekte, Multi-User Server System) sollte man das nur sehr selektiv einsetzen. Meine Vorstellung ist diese: Einen guten O/R Mapper einsetzen für sowas wie documentdetails, user/groups, category Admin Seiten etc. Für indexresults, notifications, etc. eher wie gehabt: Spezielle, handgetune'te SQL Abfragen mit eigenem Caching Mechanismus.