Ist es besser, Modellklassen zu erstellen oder bei der generischen Datenbankdienstklasse zu bleiben?

Question

Wir haben eine einfache Dienstklasse für unsere Datenbankaufrufe (ein einfacher Wrapper um ADO.NET), aber ich denke daran, Klassen für jede Datenbank/jedes Objekt zu erstellen. Wäre es klug, dies zu tun, oder wäre es nur von Vorteil, wenn wir das vollständige MVC-Framework für ASP.NET verwenden würden?

So haben wir diese:

SQLWrapper.GetRecordset(connstr-alias, sql-statement, parameters); 
SQLWrapper.GetDataset(connstr-alias, sql-statement, parameters); 
SQLWrapper.Execute(connstr-alias, sql-statement, parameters); 

Denken, dies zu tun:

Person p = Person.get(id); 
p.fname = "jon"; 
p.lname = "smith"; 
p.Save(); 

oder für einen neuen Rekord -

Person p = new Person(); 
p.fname = "Jon"; 
p.lname = "Smith"; 
p.Save(); 
p.Delete(); 

diese klug sein würde, oder wäre es Overkill? Ich sehe den Nutzen für die Wiederverwendung, die Änderung der Datenbank und die Wartung/Lesbarkeit.

Answer 1

Diese Frage ist geladen, datengesteuertes Design vs. domänengesteuertes Design. Für jede Anwendung, die ein gutes Verhalten aufweist, sollte das domänenbasierte Design bevorzugt werden. Reporting- oder Utility-Anwendungen arbeiten mit datengesteuertem Design tendenziell besser (oder sind schneller zu entwickeln).

Was Sie fragen, ist, "sollte meine Firma eine grundlegende Verschiebung in, wie wir unseren Code entwerfen" machen. Als ein Domain-Freak ist meine Bauchreaktion zu schreien ja. Aufgrund der einfachen Art Ihrer Frage bin ich mir jedoch nicht sicher, ob Sie den Umfang der von Ihnen vorgeschlagenen Änderung vollständig verstanden haben. Ich denke, du solltest mehr mit deinem Team darüber reden.

Holen Sie sich Literatur, wie Evan's DDD Buch, oder die free foundations ebook, und dann werden Sie in einer besseren Position sein, um zu beurteilen, in welche Richtung Sie gehen sollten.

Answer 2

Auf keinen Fall ist MVC das einzige Entwurfsmuster für das Web, aber es ist ein nützliches.

Allein die Übernahme des "M" zahlt sich meiner Meinung nach aus, auch wenn Sie das "V" oder "C" nicht übernehmen können/wollen.

Answer 3

Für mich sieht es so aus, als ob Sie versuchen, das zu tun, was LINQ bereits für Sie tun kann. Wenn Sie in einem älteren Framework stecken bleiben, in dem Sie das nicht verwenden können, würde ich vorschlagen, dass Sie Subconic (http://subsonicproject.com/) verwenden, anstatt alle diese Modellobjekte von Hand manuell erstellen zu müssen.

Ich hatte ein Projekt, in dem ich in einer ähnlichen misslichen Lage war und auf halbem Weg zu subsonic mit fantastischen Ergebnissen wechselte. Schnellere Entwicklung und viel einfacher zu lesen/zu verwenden Code.

Answer 4

Der Ansatz, den Sie diskutieren, wird von vielen Leuten als gut betrachtet, ich eingeschlossen! Das Erlernen dieses Ansatzes erfordert einige Anstrengungen, aber lassen Sie sich davon nicht abschrecken!

Wie wäre es mit einem kleinen Projekt mit LINQ to SQL? Vielleicht finden Sie eine auf google code, und studieren, wie andere damit gearbeitet haben.

Es ist ein einfaches Tool, mit dem Sie sich mit einigen Problemen bei der Zuordnung von Objekten zu Datenbanken vertraut machen können.

Sie können dann bekommen ein Gefühl für sie, und entscheiden, ob es die Lernkurve wert ist.

Es wird neue Konzepte und Experiment zu begreifen mit, Dinge wie:

• Arbeitseinheit: Wenn Sie auf Speichern ausführen und etc löschen, ein ORM neigt dies nicht sofort zu tun, während ein Recordset basiert DAL wird. Das kann überraschend sein, also müssen Sie etwas darüber lernen. Lesen Sie auf dem Unit of Work Muster, um ein Verständnis dafür zu bekommen.
• Massenoperationen sind ein Problem mit OR/M. Ein Datenleser kann effizient durch Tausende von Zeilen iterieren, aber bei einem ORM müssen Sie beim Arbeiten mit großen Objektmengen vorsichtig sein. Noch einmal, einen zu lesen.
• Assoziationen scheinen groß, wenn Dinge wie customer.Orders.Count tun können, aber sie sind auch die Ursache für viele Probleme. Sie müssen einige sichere Vorgehensweisen finden, die bei der Arbeit mit Assoziationen zu beachten sind.

... um nur einige zu nennen.

Für den Anfang, mach dir keine Sorgen über Vererbung und so, einfach nur starten und haben einfache Entitäten, die Tabellen zuordnen.

Versuchen Sie, sie so zu verwenden, wie Sie Ihre vorhandene DAL verwenden würden. Dann experimentiere mit Assoziationen.

Dann versuchen Sie vielleicht, mehr Verhalten in Ihre Entitäten zu bringen. Wenn Sie dies mögen und das Gefühl haben, dass Sie mehr Funktionen benötigen, sollten Sie ein funktionsreicheres ORM wie Lightspeed oder NHibernate ausprobieren.

Hoffe, das hilft!