Menu
After reading several articles, I am starting to understand the difference between DAO and Repositories, but I find myself in trouble trying to understand the difference between Repositories and Services.
For putting in short terms, in the OO paradigm:
DAO : Class that contains the basic CRUD operations for one entity class. It has the necessary code to get or retrieve things of the underlying persistent storage system. Generally speaking, the methods receive object entities as parameters, except in the retrieve method where using a type of the Identifier is valid.
Repositories : In a higher level of abstraction.. as generally I have read is a kind of place where put code that handle operations over aggregate objects (objects that have child objects). It uses the DAOs to retrieve objects from the database, and in the end it exposes an interface in the domain "business" language. (But again, I think it is very valid to use data types of ids). Example : A very simple addSomething where something is a child object of the parent whose instances, btw, are managed as a whole by the Repository.
Services : Again, it is in a higher level of abstraction. To my humble point of view they are a good place to connect two classes that do not share parent-child relation, but is as far (in abstraction terms) as Repository. Example : The method transferCash between two bank accounts.
So, that's are my readings about, but I am asking here the above thoughts are right or not. Or how I should think. Or something that points me to really understand the difference of all this concepts.
Some of the sources :
364
DAO is an abstraction of data persistence. Repository is an abstraction of a collection of objects. DAO would be considered closer to the database, often table-centric. Repository would be considered closer to the Domain, dealing only in Aggregate Roots.
In DDD, a repository is an objcect that participates in the domain but really abstracts away storage and infrastructure details. Most systems have a persistent storage like a database for its fully functioning. Applying repositories happens by integrating and synchronizing with existing aggregate objects in the system.
Services are first-class citizens of the domain model. When concepts of the model would distort any Entity or Value Object, a Service is appropriate. From Evans' DDD, a good Service has these characteristics: The operation relates to a domain concept that is not a natural part of an Entity or Value Object.
Data Access (DAO) – Meeting, Meeting Space (represents all the meetings between two people), Meeting Content (talking points for a meeting) Service – A service for each DAO object.
However, a repository can use a DAO for accessing underlying storage Also, if we have an anemic domain, the repository will be just a DAO. Additionally, the repository pattern encourages a domain-driven design, providing an easy understanding of the data structure for non-technical team members, too.
Both Repositories and DTOs can simplify database persistence by mapping persisted data to equivalent collection of entity objects. However, Repositories are more coarse-grained than DAOs by providing control of an entire Aggregate Root (AG) often hiding a lot of internal state from the client.
Repositories : In a higher level of abstraction.. as generally I have read is a kind of place where put code that handle operations over aggregate objects (objects that have child objects). It uses the DAO s to retrieve objects from the database, and in the end it exposes an interface in the domain "business" language.
Which layer Repositories belong: the Domain Layer, Persistence Layer or something in the middle? I would say there are three distinct layers in DDD applications - the inner domain layer, the outer application layer, and the external world (includes the API/UI).
Repositories are - like you say - an abstraction. They originate from Martin Fowler's Object Query Pattern. Both Repositories and DTOs can simplify database persistence by mapping persisted data to equivalent collection of entity objects. However, Repositories are more coarse-grained than DAOs by providing control of an entire Aggregate Root (AG) often hiding a lot of internal state from the client. DAO's on the other hand can be as fine-grained as being dedicated to a single entity object. For both Repositories and DAOs it is common to use Hibernate or other Object/Relational Mapping (ORM) Frameworks instead of writing your own implementation.
Typically, services can reside in a Service Layer and can act both as a functionality facade, anti-corruption layer and coordinator for caching & transaction. They are often a good place to conduct logging. Services coarse-grained and usecase-oriented, e.g. Service.updateCustomerAdress() or Service.sendOrder(). Repositories can be too fine-grained for clients to consume, e.g. Customer.add(…), Order.modify(…).
Repositories and DAOs have the same purpose - to persist data permanently. Services on the other hand should be ignorant of persistence and have no knowledge about your database. They usually work tightly together with domain services, repositories, domain core.
78
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
