Ich versuche, meine Fähigkeiten als Designmuster aufzufrischen, und ich bin gespannt, was die Unterschiede zwischen diesen Mustern sind. Alle scheinen dasselbe zu sein - kapseln Sie die Datenbanklogik für eine bestimmte Entität, sodass der aufrufende Code keine Kenntnis von der zugrunde liegenden Persistenzschicht hat. Nach meiner kurzen Recherche implementieren alle normalerweise Ihre Standard-CRUD-Methoden und abstrahieren die datenbankspezifischen Details.
Was ist der Unterschied, abgesehen von Namenskonventionen (z. B. CustomerMapper vs. CustomerDAO vs. CustomerGateway vs. CustomerRepository)? Wenn es einen Unterschied gibt, wann würden Sie einen über den anderen wählen?
In der Vergangenheit habe ich Code ähnlich dem folgenden geschrieben (natürlich vereinfacht - ich würde normalerweise keine öffentlichen Eigenschaften verwenden):
public class Customer
{
public long ID;
public string FirstName;
public string LastName;
public string CompanyName;
}
public interface ICustomerGateway
{
IList<Customer> GetAll();
Customer GetCustomerByID(long id);
bool AddNewCustomer(Customer customer);
bool UpdateCustomer(Customer customer);
bool DeleteCustomer(long id);
}und haben eine CustomerGatewayKlasse, die die spezifische Datenbanklogik für alle Methoden implementiert. Manchmal habe ich keine Schnittstelle verwendet und alle Methoden auf dem CustomerGateway statisch gemacht (ich weiß, ich weiß, das macht es weniger testbar), damit ich es so nennen kann:
Customer cust = CustomerGateway.GetCustomerByID(42);Dies scheint das gleiche Prinzip für die Data Mapper- und Repository-Muster zu sein. Das DAO-Muster (das ist, glaube ich, dasselbe wie Gateway?) scheint auch datenbankspezifische Gateways zu fördern.
Vermisse ich etwas Es scheint ein bisschen seltsam, 3-4 verschiedene Möglichkeiten zu haben, genau dasselbe zu tun.
quelle
In der Welt des Software-Designs besteht die Tendenz (zumindest glaube ich), neue Namen für bekannte alte Dinge und Muster zu erfinden. Und wenn wir ein neues Paradigma haben (das sich vielleicht geringfügig von bereits bestehenden unterscheidet), enthält es normalerweise eine ganze Reihe neuer Namen für jede Stufe. "Business Logic" wird also zu "Services Layer", nur weil wir sagen, dass wir SOA ausführen, und DAO wird zu Repository, nur weil wir sagen, dass wir DDD ausführen (und jeder von diesen ist eigentlich gar nichts Neues und Einzigartiges, aber wieder: neue Namen für bereits bekannte Konzepte, die im selben Buch zusammengefasst sind). Ich sage also nicht, dass all diese modernen Paradigmen und Akronyme genau dasselbe bedeuten, aber Sie sollten wirklich nicht zu paranoid sein. Meistens sind dies die gleichen Muster, nur aus verschiedenen Familien.
quelle
Data Mapper vs Table Data Gateway Um es kurz zu machen:
Am Ende fungieren beide als Vermittler zwischen den In-Memory-Objekten und der Datenbank.
quelle
Du hast einen guten Punkt. Wählen Sie diejenige aus, mit der Sie am besten vertraut sind. Ich möchte auf einige Dinge hinweisen, die zur Klärung beitragen können.
Das Table Data Gateway wird hauptsächlich für eine einzelne Tabelle oder Ansicht verwendet. Es enthält alle Auswahlen, Einfügungen, Aktualisierungen und Löschungen. Der Kunde ist also in Ihrem Fall eine Tabelle oder eine Ansicht. Eine Instanz eines Tabellendaten-Gateway-Objekts behandelt also alle Zeilen in der Tabelle. Normalerweise bezieht sich dies auf ein Objekt pro Datenbanktabelle.
Während Data Mapper unabhängiger von jeder Domänenlogik ist und weniger gekoppelt ist (obwohl ich glaube, dass es entweder eine Kopplung gibt oder keine). Es ist lediglich eine Zwischenschicht, um die Daten zwischen Objekten und einer Datenbank zu übertragen und sie gleichzeitig voneinander und vom Mapper selbst unabhängig zu halten.
Normalerweise sehen Sie in einem Mapper Methoden wie Einfügen, Aktualisieren, Löschen und im Tabellendaten-Gateway finden Sie getcustomerbyId, getcustomerbyName usw.
Das Datenübertragungsobjekt unterscheidet sich von den obigen zwei Mustern hauptsächlich, weil es ein Verteilungsmuster und kein Datenquellenmuster wie die obigen zwei Muster ist. Verwenden Sie es hauptsächlich, wenn Sie mit einer Remote-Schnittstelle arbeiten und Ihre Anrufe weniger gesprächig gestalten müssen, da jeder Anruf teuer werden kann. Entwerfen Sie daher normalerweise ein DTO, das über Kabel serialisiert werden kann und alle Daten zum Anwenden weiterer Geschäftsregeln oder zur Verarbeitung zum Server zurückführt.
Ich bin mit Repository-Mustern nicht vertraut, da ich bis jetzt keine Gelegenheit hatte, sie zu verwenden, aber ich werde mir andere Antworten ansehen.
quelle
Unten ist nur mein Verständnis.
TableGateWay / RowDataGateWay : In diesem Zusammenhang verweist Gateway auf eine bestimmte Implementierung, bei der jedes " Domänenobjekt " jedem "Domänenobjekt-Gateway" zugeordnet ist. Wenn wir beispielsweise Person haben , verfügen wir über ein PersonGateway zum Speichern des Domänenobjekts Person in der Datenbank. Wenn wir Person, Mitarbeiter, Kunde usw. haben, haben wir PersonGateway, EmployeeGateway und CustomerGateway. Jedes Gateway verfügt über eine spezifische CRUD-Funktion für dieses Objekt und hat nichts mit einem anderen Gateway zu tun. Hier gibt es keinen wiederverwendbaren Code / Modul. Das Gateway kann weiter in RowDataGateway oder TableGateway unterteilt werden, je nachdem, ob Sie eine "ID" oder ein "Objekt" übergeben. Das Gateway wird normalerweise mit dem aktiven Datensatz verglichen. Es bindet Ihr Domänenmodell an das Datenbankschema.
Repository / DataMapper / DAO : Sie sind dasselbe. Sie alle beziehen sich auf die Persistenzschicht, die Datenbankentitäten an das Domänenmodell überträgt. Im Gegensatz zum Gateway verbergen Repository / DataMapper / DAO die Implementierung. Sie wissen nicht, ob sich hinter Person ein PersonGateway befindet. Es kann sein, oder es kann nicht, es ist dir egal. Sie wissen lediglich, dass für jedes Domänenobjekt CRUD-Operationen unterstützt werden müssen. Es entkoppelt die Datenquelle und das Domänenmodell.
quelle