Verwendung von Datenbanktabellen als Objekte?

Question

Ich habe gerade begonnen, an einem bestehenden (Start) Projekt zu arbeiten, um es strukturell und auch in der Leistung zu reorganisieren. Ich arbeite normalerweise mit EF als Framework, aber ich bin auch mit Linq-to-sql und ADO vertraut. Was ich sehe, ist, dass die Webanwendung die aktuellen Datenbanktabellen & Ansichten als Objekte innerhalb des Codes verwendet, also beispielsweise Tabelle 'foo', die sie als ein Objekt verwenden würden, anstatt Klassen zu verwenden, um zu übergeben Daten in der App ablegen und schließlich in den DB/Tabelle einfügen. Da ich das nie gesehen habe und mir dessen nicht bewusst war, frage ich mich, ist das eine "gute" Praxis, ich meine, Microsoft hat es möglich gemacht, es so zu machen, was ist der "wahre" Zweck, gibt es Vorteile/Nachteile?

Vielen Dank für Ihre Antworten! Mit freundlichen Grüßen

Answer 1

Also, da Sie meinen Kommentar mochte ich erweitern. Lassen Sie uns sagen, ich habe Tabellen

Foo 
FooId int 
Desc varchar(32) 

Bar 
BarId int 
Desc varchar(32) 

nun eigentlich viel mehr und sagen 50 Tische habe ich so tun lassen. Ich würde das alles nicht mit der Hand machen wollen, da es irgendwie verrückt wäre. Zurück in den Tag mit ADO.NET würden Sie DataTables erstellen und möglicherweise gut geformte Objekte handcraft. Nun, mit Linq To SQL haben sie ein Dokument erstellt, das den Großteil der Modellierung für Sie übernimmt, aber es war ziemlich beschränkt auf fast identisch mit dem, wie die Datenbank aussah. Aber mit Entity Framework hat MS einen Schritt weiter gegangen. Jetzt haben Sie eine Datenbankschicht, eine Zwischenschicht und eine Objektschicht. Es genügt zu sagen, dass Sie sogar Objekte manipulieren und erstellen können, die über Ihren "Kontext" hinausgehen.

Aber all das beiseite sagen wir erstellen ein Entity Framework 6.1.3 Modell und wählen Sie meine Datenbank und wählen Sie Datenbank zuerst.Ich erhalte eine Modelldarstellung, indem ich Objekte hinzufüge und sie unter einem Kontext für mich gespeichert werden. Soweit es EF betrifft, sind diese Objekte die Tabellen. Sie tun nur so etwas wie

using(var context = new DBContext()) 
{ 
    var newFoo = new Foo { Id = 1, Desc = "A" }; 
    context.Foo.Add(newFood); 
    context.SaveChanges(); 
} 

ich gerade hinzugefügt und ein neues Foo-Objekt gespeichert und ich musste nicht jeder Code Erstellung eines POCO Objekt zu tun. EF hat das für mich getan, als ich das benutzerdefinierte Werkzeug ausführte, indem ich das Modellobjekt anwählte und mit der rechten Maustaste klickte und "Benutzerdefiniertes Werkzeug ausführen" auswählte. Im Wesentlichen werden hier nur die Daten ausgeführt, um die POCOs und Einstellungen für Sie zu generieren. Oder Code schreiben Code in der T4. Sie können das T4 aktualisieren, um Einstellungen zu ändern, aber ich empfehle nicht, zu verrückt zu werden.

Die Methode, die Sie bereits gehen, ist besser. Einfach den Code in neue Methoden einbinden und schon hast du ein Repository. Der Vorteil eines Repositories, das EF-Kontexte direkt in die Hand gibt, ist, dass Sie Technologien mischen oder nach Bedarf ändern können. Das einzige, was ich sagen würde, wäre, die Objekte, die Sie verwenden, als das zu behalten, was die EF oder andere Technologie erzeugt. Oder vielleicht haben Sie eine Geschäftslogik mit Eigenschaften, die automatisch aufgerufen werden, und Sie möchten nicht, dass sie Ihre EF verschmutzen, aber in einem Repomuster sind sie in Ordnung. Repository-Muster IMHO sollte nur ein Vermittler für Ihre CRUD-Operationen sein, die zwischen einer Retrieval-Technologie und einem Anrufteil liegen.

Answer 2

Ich habe Repositories als Objekte in Java und C# vor gesehen. Ich vermute, das ist es, worüber du hier redest. Wenn ja, gibt es einen signifikanten Kompromiss. Wie bei mot-Tools ist es wichtiger, wie Sie es verwenden, als wenn Sie es verwenden. Um die Kompromisse zu verstehen, ist es wichtiger, eine allgemeine Nutzungsregel zu haben.

Normalerweise haben wir mit einem Repository ein Objekt, das für das Speichern und Abrufen unserer Daten verantwortlich ist. Dies kann wie eine Datenbanktabelle funktionieren, ist aber eine Abstraktion, die sich zwischen Ihrer Datenbank und Ihrer Anwendung befindet. Darin beharren Sie Objekte und von diesem fordern Sie Objekte an. Das Repository hat keine Kenntnis von den Interna der Objekte und weiß nur, wie man sie speichert oder bekommt. Es ist ein allgemeines Muster im Frühling, zum Beispiel.

Ein Repository ist sehr ähnlich zu Datenzugriffsobjekten (und tatsächlich argumentieren einige Leute, dass sie dasselbe sind und andere argumentieren, dass sie das nicht sind).

Der Vorteil ist, dass Sie diese Abstraktion später haben, wenn Sie die Objekte woanders speichern wollen (zB wollen Sie sie stattdessen in Kafka schreiben und später in die Datenbank schreiben), haben Sie ein Repository, das dies kann . Das Repository muss Ihnen also nicht sagen, wie es zu den Daten kommt oder bleibt. Es muss lediglich eine API implementieren, für die Sie sich entscheiden.

Ein wichtiger Vorteil hier ist, dass Sie Ihre Geschäftslogik von Ihrer Persistenz-Logik trennen (was bedeutet, dass Sie beide ändern können, ohne sich um die andere Gedanken zu machen). Der Nachteil ist, dass diese immer noch eng gekoppelt sind, so dass die Abstraktion Sie nicht so viel kauft, wie Sie vielleicht denken und es kostet mehr Komplexität, als Sie vielleicht denken.

Ich bin sicher, es gibt Code-Generatoren, um dies gegen Tabellen in SQL Server zu tun. In dem Moment, in dem Sie dies tun, binden Sie sich jedoch mehr oder weniger an API-Entscheidungen der Code-Generatoren, die den Zweck, die Abstraktion dort zu haben, teilweise zunichte machen.