Ich bin mir bewusst, dass diese Frage ein wenig gefährlich zu fragen ist, aber ich brauche wirklich eine Meinung dazu.
Wir haben unser System, es ist eine Website (wird ein beliebtes Webportal, wir benutzen MVC3) und bevor ich hier war, haben die anderen meine Kollegen NHibernate als ihre OR Mapper-Lösung gewählt, und sie begannen, Kriterienabfragen zu schreiben und so ..
Im Moment ist das Team näher am Linq-Ansatz, also haben wir versucht, Abfragen im eingebauten Linq-Provider zu schreiben. Das Ding ist .. es ist schrecklich angepasst - buchstäblich kann man nicht-triviale Abfragen schreiben und bekommt nicht Not supported exception ...
Wir haben beschlossen, dass es der letzte mögliche Moment ist, unseren OR-Mapper auf etwas mehr Linq-basierendes zu ändern und wir seit der EF4.1 ultra-freundliche Code-First-Option haben, dass wir das brauchen.
Das Problem, dass ich einige Meinungen dazu brauche, ist die Zeit wert, von NHibernate auf EF4.1 zu migrieren ... Das Projekt wird mindestens ein Jahr weiter in der Entwicklung dauern, also haben wir eine Menge Arbeit zu tun, und wir wollen es auf nette und nicht frustrierende Weise machen.
Einige Fakten:
Also .. jetzt .. ist Migration eine gute oder schlechte Idee? Wird EF unsere Probleme lösen, wird es uns glücklich machen oder wird dieser Schritt nur die Verschwendung unserer Zeit sein?
Grüße
Ich muss @Ladislav zustimmen, EF und LINQ ist nett, es funktioniert nur im Vergleich zu NHibernate LINQ, aber die SQL EF generiert manchmal ist ziemlich schrecklich und ist nicht sehr performant und Sie werden gezwungen, komplexe Abfragen in Ansichten und SP usw. Nhibernate kann auch in diese Falle fallen, aber mit vielen verschiedenen Optionen ist ein Vorteil, wie Sie die beste für Ihre Bedürfnisse auswählen können.
Ich nehme an, Sie versuchen, Folgendes auszugleichen: -
Ein bisschen von einem ORM in einen anderen zu springen kann wie ein Sprung aus der Bratpfanne ins Feuer sein. Beide haben ihre süßen Flecken beide werden Ihre Finger verbrennen!
Seien Sie sich bewusst, dass Sie eine bessere Linq-Unterstützung für schlechtere Mapping-Funktionen und manchmal eine viel schlechtere Performance austauschen werden ( Vererbungsabfragen , keine Abfrage oder Befehlsbatching , ...). Kehre jetzt zur Tafel zurück und denke nochmal nach. Wenn Sie Ihre Datenbankleistung jetzt nicht mögen, wird sie sich mit EF kaum verbessern.
Ich denke, es ist ein bisschen spät, um die Technologie zu ändern - es wird hohe Kosten haben. Aber wie auch immer, wenn Sie es wirklich wollen, warum nicht, um Proof-of-Concept zu machen, wo Sie ein wirklich komplexes zugeordnetes Feature mit einigen erweiterten Abfragen verwenden und versuchen, das gleiche in EF-Code zuerst zu tun? Sie können das gleiche einfach in einer einfachen Konsolenanwendung testen und sowohl Mapping-Erfahrung als auch Abfragen und Leistung vergleichen.
Leistung ist im Moment vielleicht kein Problem, aber es kann etwas sein, das Sie in Zukunft wirklich optimieren müssen, und EF wird Ihnen viel weniger Funktionen dafür bieten. Wenn Sie die Leistung der EF-Lösung verbessern möchten, kehren Sie sehr oft zu nativem SQL und gespeicherten Prozeduren zurück. Haben Sie eine bessere Erfahrung für das Schreiben von Abfragen?
Ich persönlich stoße auch auf die Probleme mit dem Linq-Provider für Nhibernate.
Allerdings habe ich beschlossen, bei NHibernate wegen seiner "richtigen" SQL-Generation, der allgemeinen Leistung und Erweiterbarkeit zu bleiben.
Letzteres ermöglicht es Ihnen, Ihr RDBMS mit einem zweiten Level-Cache Ihrer Wahl wie MemcacheD zu lindern. Es behält die Objekte im Speicher (auf dem MemcacheD-Server), um sie nur bei Bedarf von / zu dem RDBMS zu holen / zu übergeben. Gilt auch für kompilierte SQL-Abfragen.
Nun, um ehrlich zu sein, es klingt, als ob Sie sich bereits entschieden haben. Ich bin mir nicht sicher, was du hier wirklich fragst. Wenn Sie daran interessiert sind, bei NHibernate zu bleiben, sollten Sie spezifische Fragen zu Problemen stellen, die Sie haben.
Meiner Meinung nach, wenn Ihr Team mit EF besser vertraut ist, sollten Sie wechseln. Wenn das nicht der Fall ist, bin ich mir nicht sicher, ob Sie jemals wissen werden, ob der EF alle Ihre Probleme lösen wird, wenn Sie nicht die spezifischen Probleme, die Sie haben, skizzieren.
Tags und Links c# entity-framework linq entity-framework-4.1 nhibernate