•  08-06-2019
  •  | 
  •  

Frage

Welcher Konsens herrscht darüber, wann eines dieser Tools im Gegensatz zum anderen eingesetzt werden sollte?Ich finde Subsonic sehr nützlich, wenn es darum geht, Dinge schnell zu erledigen, aber bei großen Projekten neigt es dazu, nicht skaliert zu werden, und es bindet Ihr Domänenmodell an Ihr Datenbankmodell.Hier kommt Nhibernate ins Spiel, denn es bietet Ihnen leichtgewichtige POCOs, die nichts mit Ihrem Datenbankmodell zu tun haben, aber die Einrichtungszeit ist viel länger.

Keine korrekte Lösung

Andere Tipps

Diese Frage wird mir oft gestellt und im Grunde kommt es darauf an, wie sehr man herumfummeln möchte.Ich kann Ihnen nicht sagen, wie schädlich die Kommentare von Chris Cyvas zur RE SubSonic-Skalierung waren – und seitdem reagiere ich darauf :(.

Der Deal ist: Was die Leistung angeht, lässt sich SubSonic sehr gut skalieren.Im Hinblick auf das Projektwachstum erfordert JEDES Tool, das Sie verwenden, Ihre Aufmerksamkeit.Sogar NHibernate.

Ich habe einen Beitrag darüber geschrieben, wie man das Repository-Muster mit DI (wie man es mit NHIb oder einem anderen Tool tun würde) mit SubSonic 2.1 verwenden kann:

http://blog.wekeroad.com/blog/subsonic-writing-de Coupled-testable-code-with-subsonic-2-1/

Ich habe auch einen Beitrag zur Leistung von SubSONic geschrieben:

http://blog.wekeroad.com/blog/subsonic-scaling/

Hoffe das hilft.

Ich würde SubSonic empfehlen, wenn Ihr Projekt mit der ActiveRecord-Ansicht arbeitet, dass die Datenbank Ihr Modell ist.Sie erhalten eine Unterrichtsstunde pro Tisch und alles funktioniert wie von Zauberhand.Sie können natürlich Dinge anpassen und überschreiben, aber wenn Sie (oder Ihr Projekt) grundsätzlich mit dem Klasse-pro-Tabelle-Ansatz nicht einverstanden sind, würde ich mir NHibernate ansehen, da es mit dem komplexeren (aber flexibleren) Ansatz der Zuordnung Ihrer Klasse beginnt Domänenmodell in Ihre Datenbank einbinden.

Wenn Sie eine relativ einfache Datenbank verwenden, die unter Ihrer Kontrolle steht (z. B. können Sie Spalten ändern, ohne acht Formulare an ein Aufsichtsgremium für die Datenbankabteilung zu senden), würde ich empfehlen, mit SubSonic zu beginnen und zu NHibernate zu wechseln, wenn SubSonic dies nicht tut entspricht deinen Bedürfnissen.

Was es wert ist ... Seitdem ich diese Frage gestellt habe, hatte ich die Gelegenheit, beide Technologien deutlich häufiger zu nutzen.Und ich muss dabei bleiben, dass es sehr wenig ausmacht, wenn man sich für diese Technologien entscheidet.Sicherlich ermöglicht NHibernate eine etwas geringere Kopplung Ihrer Geschäftseinheiten an Ihre Datenbankstruktur, aber ich finde dennoch, dass es viele Fälle gibt, in denen Sie sich immer noch dem Willen der Datenbank beugen müssen.

Meiner Meinung nach besteht die einzig wahre Möglichkeit, Ihr Domänenmodell vollständig von Ihrem Datenbankmodell zu trennen, darin, ein eigenes zu schreiben DTOS (im Wesentlichen POCOs zur Weitergabe von Daten) und ordnen Sie sie dann wieder dem ORM Ihrer Wahl in Ihrer Datenschicht zu.Aber in den meisten Fällen wird mir dieser Ansatz mehr Ärger bereiten, als er wert ist.

Etwas abseits des Themas, aber in ähnlicher Weise.Hast Du Dir angesehen Castle ActiveRecord es steht darüber geschrieben NHibernate und macht den Zeitaufwand für die Erstellung von XML-Zuordnungen vom Code zur Datenbank überflüssig.Wie NHibernate können Sie Ihre Domänenobjekte nach Ihren Wünschen strukturieren und später aus dieser Struktur ein Datenbankschema generieren.

Benutzen ActiveWriter, einem beigesteuerten Tool, können Sie Ihre Datenbank ganz einfach auf Domänenobjekte abbilden.

Sie können einen Blick auf Fluent NHibernate werfen.Es macht die Verwaltung von NHibernate zum Kinderspiel.Ich bin mir nicht sicher, wie schwierig es wäre, ein vorhandenes Schema zu übertragen, aber wenn Sie eine neue Anwendung erstellen, ist es hilfreich, das Domänenmodell zu definieren und die Datenbank auf praktisch jedem erdenklichen DB-Server zu generieren.Wenn ich die anderen Kommentare hier lese, denke ich, dass Fluent NHibernate NHibernate hinsichtlich der einfacheren Konfiguration auf Augenhöhe mit SubSonic bringt.

Ich kann keinen guten Vergleich anstellen, da ich NHibernate noch nicht für ein Projekt verwendet habe, aber ich habe SubSonic verwendet und war sehr zufrieden damit.Bisher bin ich bei der Nutzung auf keine größeren Hürden gestoßen.

Kasse dieser Beitrag von Rob Conery, einem der Schöpfer von SubSonic.Er spricht darüber, wie Sie Ihren SubSonic-Code vom Rest der App entkoppeln können.Er erwähnt sogar die Tatsache, dass diese Architektur es Ihnen ermöglichen würde, SubSonic später gegen eine andere Datenzugriffsschicht wie NHibernate oder LINQ to SQL auszutauschen.

Ich weiß, dass ich Ihre Frage nicht wirklich beantwortet habe, aber ich hoffe, dass das trotzdem hilft.

ICH hat einen Blogbeitrag geschrieben kürzlich über .NET ORMs, die Subsonic enthalten, und ActiveRecord.Meiner Erfahrung nach hängt es davon ab, was das Projekt macht. Subsonic funktioniert viel besser, wenn man einen SQL-Hintergrund hat, aber NHibernate hat mehr drauf.ActiveRecord eignet sich gut für kleinere Projekte. Ich bin nicht davon überzeugt, dass es bei größeren Projekten schneller ist als das Festhalten an NHibernate.

Ich habe beide bewertet und glaube, dass es nicht fair wäre, das eine dem anderen vorzuziehen, ohne zu verstehen, was Ihre Ziele sind.In Ihrer Frage haben Sie die Unterschiede gut dargelegt, und ich glaube, dass dies Ihr entscheidender Faktor sein muss.Persönlich habe ich beide verwendet und werde je nach Projekt weiterhin beide verwenden.

  • NHibernate ist meine Wahl für größere Projekte, da es leichte POCOs verwendet.Wenn ich jemals mein ORM „glaube“ austauschen würde, wäre die Umgestaltung viel einfacher.
  • SubSonic ist meine Wahl, wenn ich ein kleineres Projekt habe.Ich glaube, dass sich SubSonic leistungsmäßig gut skalieren lässt.Allerdings fühle ich mich eng damit verbunden, weil es so tief in mein Projekt eingraviert ist.Bei kleineren Projekten kann ich es immer noch austauschen, weil die Codebasis so klein ist und es mir wirklich hilft, Code wie angekündigt herauszureißen.

Auch hier etwas abseits des Themas, aber ich schließe mich dem an Castle ActiveRecord - Anstatt die Datenbank als Modell zu verwenden (Subsonic-Ansatz) oder Stunden mit XML-Spaghetti zu verbringen (NHibernate-Ansatz), platzieren Sie einfach Attribute in Ihren Modellklassen.

Sie können sogar ActiveRecord herunterladen Generieren Sie das Datenbankschema für dich.

Wir haben diesen Ansatz mittlerweile bei zahlreichen Projekten verwendet und die Vorteile sind wie folgt:

  • Einfacher Upgrade-Pfad auf NHibernate, falls in Zukunft erforderlich
  • Unterstützung für einfache Vererbungsmodelle - z.B.Auto -> Fahrzeug
  • Das generierte Schema ist höchstwahrscheinlich so, wie Sie es ohnehin erstellt hätten, sodass Sie mehr Zeit mit der Erstellung der App verbringen können, anstatt sich darum zu kümmern, Ihr Modell/Ihre Datenbank synchron zu halten.

Ich denke, du hast es ziemlich gut hinbekommen.Subsonic generiert Code, sodass Ihre Geschäftsobjekte Ihre Datenbankstruktur widerspiegeln.nHibernate verwendet Zuordnungsdateien, die Ihre Geschäftsobjekte der Datenbank zuordnen, sodass Ihre Objekte nach Ihren Wünschen strukturiert werden können.

Wie groß ist das Projekt?Wird eine langfristige Unterstützung benötigt?Wird die Kosteneffizienz von Subsonic mögliche Skalierungsprobleme ausgleichen?

Wir haben das Bootstrapping mit Subsonic durchgeführt und versuchen nun zu beurteilen, ob wir jetzt, da wir uns an den Schwachstellen von Subsonic befinden, auf den Ruhezustand umsteigen werden.

Unsere andere Möglichkeit besteht darin, einen Mittelweg zu schaffen, bei dem wir Subsonic verwenden, um beliebige Objekte mit ihrer Funktion „Als typisierte Liste ausführen“ abzufragen und zu laden, die eine namensbasierte Zuordnung einer beliebigen SQL-Anweisung im Linq-Stil durchführt.Oder versuchen Sie, einen Teil davon in nhibernate neu zu erstellen und den Rest umzugestalten.

Ich sage also, dass Subsonic in kleinen Apps sinnvoll ist, aber die Wartung von Subsonic-Apps wird ziemlich umständlich, wir haben es besonders schwer mit überlappendem Validierungscode und durch Pre-/Post-in-Code ausgelösten Ereignissen.Bei einem aktiven Aufzeichnungsmuster ist „subsonic“ definitiv zu 80 % vorhanden, macht aber etwas Flauteiges und verhindert, dass Sie wirklich Kontrolle über Ihre Vererbungshierarchie haben, da jede Klasse eine Tabelle erben muss, um zu dieser Tabelle zurückzukehren.

Berücksichtigen Sie die Größe Ihres Teams und Ihres Projekts, wenn Sie ActiveRecord in Betracht ziehen.

Meiner Erfahrung nach ist ActiveRecord eine Abstraktion auf NHibernate, die beim Ausprobieren komplizierterer Szenarien wie ein Sieb zu lecken beginnt.

Wenn Sie ein mäßig bis stark kompliziertes oder nicht einfaches Schema haben, bleiben Sie bei NHibernate.Sie können es nahezu perfekt schneiden und würfeln.

Sie könnten auch dann in Schwierigkeiten geraten, wenn Sie eine mäßig komplizierte Abfrage benötigen.ActiveRecord verbirgt viele Implementierungen von NHibernate ...Sie benötigen es jedoch für eine komplizierte Abfrage, die sehr schwierig werden wird, wenn Sie mit HQL völlig unbekannt sind.Seien Sie vorsichtig, Teammitglieder hacken nicht einfach an den Rändern herum, anstatt NHibernate und HQL zu lernen.

Akzeptieren Sie die Impedanzinkongruenz!

Schauen Sie sich das an

:)

Oder nicht.Wenn Sie Leistung wollen, machen Sie es selbst.Wenn Sie es schnell und einfach wollen, entscheiden Sie sich für NHibernate und ActiveRecord.Wenn Sie gerne so tun, als wüssten Sie tatsächlich, was auf Datenzugriffsebene vor sich geht, verwenden Sie NHibernate und sitzen Sie den ganzen Tag mit XML herum, um viele zu viele in Gang zu bringen ...Oder nur...irren..Mach es selbst - ADO.Net FTW!

Ich bin der Meinung, dass Sie sich an die Lösung halten sollten, die Sie am besten nutzen können.Das ultimative Ziel ist die Produktivität und die Qualität des Codes mit guter Leistung.Wenn Sie SubSonic in- und auswendig kennen, bleiben Sie dabei, und wenn Sie NHibernate im Detail kennen, bleiben Sie bei NHibernate.Das ist eine sehr subjektive Frage.Sie sollten auch die Tatsache berücksichtigen, worüber Ihr Teammitglied Fachwissen hat.Wenn Sie gut darin sind, können Sie es problemlos pflegen.

Ich habe große Projekte mit SubSonic gesehen, während NHibernate bereits bekannt ist und weit verbreitet verwendet wird.

Die Entscheidung, sich für ORM zu entscheiden, trifft nicht zu hängen ausschließlich vom ORM selbst ab.

Der Rat, den ich zu diesem Thema erhalten habe, ist, dass Subsonic nicht für die Bewältigung komplexerer Szenarien skaliert werden kann. Wenn Sie also diesen Weg einschlagen, müssen Sie am Ende versuchen, auf ein fortgeschritteneres ORM umzusteigen.

Ich interessiere mich daher mehr für die Verwendung von NHibernate für komplexe Fälle, Castle Active Record für einfachere Fälle und behalte Fluent NHibernate im Auge, was die NHibernate-Zuordnung erheblich vereinfachen dürfte (insbesondere, wenn die konventionsbasierte Zuordnungsunterstützung verbessert wird).

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top