Ich war erfolgreich mit dem Schreiben meines eigenen SQL-Zugriffscodes mit einer Kombination aus gespeicherten Prozeduren und parametrisierten Abfragen und einer kleinen Wrapper-Bibliothek, die ich geschrieben habe, um den ADO.NET-Grunge zu minimieren. Das alles hat in der Vergangenheit sehr gut funktioniert und ich war ziemlich produktiv.Oldschool-SQL-DB-Zugriff im Vergleich zu ORM (NHibernate, EF, et al.). Wer gewinnt?
Ich bin auf dem Weg in ein neues Projekt - sollte ich meine alte Schule hinter mir lassen und mich in eine ORM-basierte Lösung stürzen? (Ich weiß, dass es zwischen NHibernate und EF große Unterschiede zwischen den Konzepten gibt. Ich möchte hier nicht näher darauf eingehen. Lassen Sie uns zur Argumentation LINQ sogar mit den Alternativen der alten Schule verbinden.) Ich suche Beratung bei der realen Anwendung von ORM-Typen gegen das, was ich weiß (und ziemlich gut weiß).
Old-School-ADO.NET-Code oder ORM? Ich bin mir sicher, dass es eine Kurve gibt - hat die Kurve einen ROI, der sich lohnt? Ich bin ängstlich und willig zu lernen, habe aber eine Frist.
Ich wünschte DotNetRocks würde die Person interviewen, die das System.Data.DataSet geschrieben hat und seine Meinung über ORM erhalten. Ich bin auch neugierig, was Funktionsprogrammierer, die F # oder ocaml verwenden, an den Overhead von ORM denken. – BuddyJoe