OOP - Wo werden die Aufrufe an die Datenzugriffsebene gesendet?

Question

Ich implementiere eine Data Access Layer (DAL), die im Grunde eine Reihe von Klassen mit (VB.NET) Shared-Funktionen ist, um die Datenbank (CRUD) -Aufrufe tatsächlich auszuführen. Ich versuche den besten Ort herauszufinden, an dem die Anrufe innerhalb der Klassenhierarchie an die DAL gerichtet werden. Lassen Sie mich ein Beispiel geben.

Angenommen, ich habe eine Klasse Customer, mit nur Standard-ID, Name, Adresse1, usw. Eigenschaften und vielleicht eine überschriebene ToString-Funktion oder so. Ich habe auch eine DAL-Klasse mit Gemeinschafts-Methoden, wie zum Beispiel:

(pseudocode) 

Namespace Dal 

Public Class Customer 

Public Shared Function Read(id As Integer) As Customer 

Public Shared Function ReadList() As List(Of Customer) 

Public Shared Sub Create(c As Customer) 

'etc. 

Nun, ich könnte die Dal von der Präsentationsschicht nennen wie so:

Me.DataGridView1.Datasource = Dal.Customer.ReadList 

Allerdings ist es nicht eine gute Praxis die Präsentationsebene überhaupt auf den Dal aufmerksam machen? Sollte ich stattdessen Methoden in das Customer-Objekt setzen und den Dal so nennen?

Public Function ReadList() As List(Of Customer) 
    Return Dal.Customer.ReadList() 
End Sub 

Public Sub Create() 
    Dal.Customer.Create(Me) 
End Sub 

Wäre das "sauberer" OOP? Oder ist es akzeptabel Praxis der Präsentation ließ die Dal nennen, vorbei an den Business-Objekte wie meine vorherigen Beispiel:

Me.DataGridView1.Datasource = Dal.Customer.ReadList 

Dim c As New Customer 
c.Name = "Alpha Corporation" 
c.Address1 = "123 Main Street" 
Dal.Customer.Create(c) 

Vielen Dank für Ihr Feedback.

Answer 1

Ich stimme zu, dass Datenaufrufe nicht in eine UI-Schicht gehören. Diese sind nur für die Präsentation gedacht.

Ich denke, sie gehören ordnungsgemäß in eine Service-Schicht. Die Service-Implementierung verwendet Modellobjekte und die Persistenzschicht, um ihre Ziele zu erreichen. Ob es sich um einen XML-basierten Webdienst oder eine lokale Schnittstelle handelt, der Dienst ist das Objekt, das Anwendungsfällen zugeordnet ist und Arbeitseinheiten kennt.

Entweder legen Sie die Datenbankaufrufe in eine separate Persistenzschicht oder betten sie in die Modellobjekte für zusätzliche objektorientierte Reinheit ein.

Answer 2

Je weniger Ihre Anwendung von Ihrer DAL weiß, desto besser. Es gibt mehrere Möglichkeiten, dies zu tun, und ich denke, Sie sind auf dem richtigen Weg. Ich denke, dass Sie für diese Implementierung in die factory pattern suchen könnten, da Sie die DAL-Implementierung hinter der Fabrik verbergen und Entitäten und Sammlungen von Entitäten von der Fabrik zurückgeben können.

Answer 3

Der Grund, warum Sie die CRUD-Operationen in eine separate Schicht ziehen möchten, ist, falls Sie jemals Datenbanksysteme ändern möchten. Nun, deshalb habe ich es getan. Ich würde das nicht empfehlen, nur um ein guter OOD zu sein. Aber hier geht ya ...

Mehrere Sätze von Klassen/Interfaces

Businessobject - Stell Entitäten Branche wie zum Beispiel eines Kunden, hat DataManager- als Eigenschaft.

DataManager- - Vielleicht haben Sie einen besseren Namen aufwarten kann, aber dieses Ding bietet Load() und Save() Funktionen für die Business

Search - Liefert Listen von Dingen, gehen Ihre SQL-Abfragen hier. Auch dies sollte sich wahrscheinlich wie ein RecordSet verhalten mit Next(), Eof() und CurrentRecord type

Constructor/Factory - Siehe FactoryPattern. Sie haben Ihre Datenbankoperationen von Ihren Geschäftsobjekten abgekoppelt. Dieses Ding verbindet sie auf eine notwendige Art und Weise.Weist eine geeignete Datenmanager-Implementierung zu BusinessObject zu

Kommen Sie mit den tatsächlichen Namen, die Sie wollen, aber sprechen wir erneut über den Kunden. Angenommen, Sie haben eine Oracle-Datenbank. Sie könnten mit dieser Klassen enden:

boCustomer die

oracleDMCustomer von Businessobject erbt, erbt oder implementiert Data

searchlistCustomer, die von Suchliste erbt, wie entweder durch abstrakte Methoden oder als Schnittstelle etwas ausgesetzt:

• SearchAll() -, die alle Kunden
• SearchByZip (String zip) zurückgeben soll, die sollte zurückkehren alle Kunden mit dem angegebenen zipcode

oracleSearchlistCustomer - implementiert searchlistCustomer, würde die SearchAll() und SearchByZip tatsächlich umzusetzen()

boFactory - statische Klasse, die eine Methode, die

so etwas wie Create (Typ Typ) sieht

searchlistFactory - statische Klasse, die eine Methode hat, die so aussieht wie CreateSearchList (Type type);

Ich lasse Sie einige der Lücken ausfüllen, aber ich denke, die wichtigen Dinge sind da. Andere haben vielleicht andere Ideen, die weniger Abstraktion erfordern. Ich würde mehrere Strategien vorspielen, bevor ich mit einem ging.