Wir beginnen gerade mit der Entwicklung einer mittelgroßen ASP.Net MVC 2-Website. Bei einer typischen Seite greifen wir auf Daten zu und werfen sie auf die Webseite, d. H. Es gibt nicht viel Vorverarbeitung der Daten, bevor sie an die Benutzeroberfläche gesendet werden.
Wir treffen jetzt die Entscheidung, ob wir ein ORM verwenden sollen und wenn ja, welches. Wir haben uns EF2 AKA EF4 (ASP.Net Entity Framework in VS 2010) als eine Möglichkeit angesehen.
Ich denke jedoch, dass eine einfache Lösung in diesem Fall nur die Verwendung von Databases sein kann. Der Grund dafür ist, dass wir nicht planen, die Daten zu verschieben oder zu verarbeiten, sobald wir sie abgerufen haben. Daher bin ich nicht sicher, ob es so viel Wert hat, stark typisierte Objekte als DTOs zu haben. Außerdem vermeiden wir auf diese Weise das Mapping insgesamt, wodurch ich glaube, dass der Code vereinfacht und eine schnellere Entwicklung ermöglicht wird.
Ich sollte erwähnen, dass das Budget bei diesem Projekt ein Problem ist, ebenso wie die Geschwindigkeit der Ausführung. Wir streben nach Einfachheit, wo immer wir können, sowohl um das Budget kleiner zu halten als auch um den Zeitplan zu verkürzen und die Leistung schnell zu halten.
Wir haben dies noch nicht vollständig entschieden, sind aber derzeit auf kein ORM ausgerichtet. Werden wir mit dem No-ORM-Ansatz einverstanden sein oder lohnt sich ein ORM?
Ein ORM-Tool ist nicht zwingend erforderlich!
Jons Rat ist vernünftig, aber ich denke, dass die Verwendung von DataTables nicht ideal ist.
Wenn Sie ein ORM-Tool verwenden, ist das Objektmodell weitaus einfacher als ein vollständiges OO-Domänenmodell. Darüber hinaus sind beispielsweise Linq2Sql und Subsonic einfach zu verwenden. Ermöglicht sehr schnelle Codeänderungen, wenn sich die Datenbank ändert.
Sie sagen, dass Sie die Daten nicht verschieben oder viel verarbeiten werden, aber die Verarbeitung in ORM-Objekten und in DataTables ist viel einfacher. Auch wenn sich die Anwendung ändert und mehr Verarbeitung erforderlich ist, wird die DataTable-Lösung fragil.
Wenn Sie keine objektorientierte Programmierung durchführen wollen (und damit meine ich, dass Sie ein tiefgründiges Verständnis von OOP haben sollten, nicht nur die Fähigkeit, Prinzipien auszuplaudern und Musternamen zu entwerfen), dann NEIN es lohnt sich nicht für ein ORM.
Ein ORM ist nur nützlich, wenn Ihre Organisation vollständig in das objektorientierte Anwendungsdesign investiert ist und somit das Problem der Zuordnung von Objekt zu relationalen Modellen hat. Wenn Sie nicht ganz auf OO setzen, werden ORMs zu einem bösen Roadblock, den Ihre Organisation dann nicht mehr braucht.
Wenn der Programmierstil Ihres Teams / Ihrer Organisation immer darauf ausgerichtet war, Geschäftslogik in der DB zu halten (zB gespeicherte Procs) oder sich beim Schreiben von Objekten und Methoden an einen mehr oder weniger funktionalen / prozeduralen / statischen Ansatz zu halten, verzichten Sie auf ORMs und Bleiben Sie bei ADO.NET.
Es klingt so, als müssten Sie nur Daten anzeigen und CRUD nicht machen.
Ich habe festgestellt, dass ORM nicht der beste Weg ist, Listen anzuzeigen, die aus Daten aus verschiedenen Tabellen bestehen. Am Ende laden Sie große Objektgraphen, nur um dieses eine benötigte Feld zu bekommen.
Eine SQL-Anweisung ist einfach so viel besser. Ich würde immer noch Listen von stark typisierten Objekten aus der DAL zurückgeben. Dadurch haben Sie eine bessere Chance, einen Kompilierzeitfehler zu erhalten, wenn sich eine Änderung in der DAL nicht in anderen Schichten widerspiegelt.
Wenn Sie bereits Prozeduren gespeichert haben, die Sie benötigen, dann gibt es wahrscheinlich nicht viel zu gewinnen von einem ORM. Wenn nicht, obwohl meine Erfahrung war, dass die Arbeit mit Linq zu Entites war viel schneller als die traditionelle gespeicherte Prozedur / stark typisierte Dataset-Ansatz vorausgesetzt, Sie sind mit Linq-Abfragen vertraut.
Wenn Sie sich keine Gedanken über die Zuordnung zu einem Objektmodell machen müssen, ist Linq to SQL noch einfacher zu verwenden. Sie müssen nicht unbedingt ein vollständiges OO-Modell verwenden, um die Produktivitätsvorteile zu nutzen.
Es würde mit Malcolm's Punkt nicht übereinstimmen, dass Graphen zurückgebracht werden müssen, wenn das ORM Linq unterstützt, können Sie eine Projektion verwenden, um ein flaches Ergebnis mit den gewünschten Daten zurückzugeben, mit dem zusätzlichen Vorteil, dass die Abfrage normalerweise einfacher ist als die entsprechende SQL da Sie Beziehungen verwenden können, anstatt sich zu verbinden.
Nachdem ich den Wechsel gemacht und mich mit der Technologie vertraut gemacht habe, kann ich mir diesen fast keinen guten Grund vorstellen, keinen zu verwenden. Sie alle unterstützen das Zurückfallen auf SQL-gespeicherte Prozeduren, wenn Sie wirklich brauchen. Es wird jedoch eine Lernkurve geben und in diesem Fall wird es sich vielleicht nicht lohnen.
Ich stimme dem Rat von Joe R zu - für die Geschwindigkeit, Änderungen vorzunehmen & amp; Auch die Geschwindigkeit der anfänglichen Entwicklung, LINQ-to-SQL oder subsonic wird Sie in kürzester Zeit auf den neuesten Stand bringen.
Wenn Ihre Anwendung wirklich so einfach ist und es sich nur um direkte Daten / Daten in direkter Zuordnung zu den Tabellen handelt, haben Sie in Betracht gezogen, ASP.net dynamische Daten ?
Ich würde auch auf eine gute Artikel zu diesem Thema von Scott Guthrie.
Es hängt weitgehend davon ab, wie vertraut Sie mit ORMs sind.
Ich persönlich bin der Meinung, dass NHibernate, der König der ORMs in der .NET-Welt, eine viel schnellere Entwicklung ermöglicht, da man nach dem Einrichten ziemlich vergessen kann, wie man Daten aus der Datenbank holt.
>Es gibt jedoch eine steile Lernkurve, besonders wenn Sie versuchen, Dinge auf nicht-hacky Weise zu tun (was Sie sollten), wenn Ihr Team also keine Erfahrung hat und die Zeit drängt, dann wahrscheinlich wird es nicht schneiden.
Linq2SQL ist viel zu einfach. Ich weiß nichts von Subsonic, aber wenn Sie ein ORM verwenden, kann es eine gute Balance sein zwischen einer schnellen Entwicklung und etwas, das zu mächtig und komplex ist.
Letztendlich denke ich, dass Sie als Team den NHibernate lernen möchten, der bei einem kleinen bis mittleren Projekt nicht zeitaufwendig ist, wenn Sie erst einmal wissen, was Sie tun, aber sehr mächtig ist.
Tags und Links asp.net-mvc entity-framework orm ado.net