We have a class in which we have methods:
- find: select + multiple joins in order to filter data
- add: insert in multiple table
- update: update in multiple table
- delete: delete in multiple table
- check: multiple select + multiple joins in order to check something
Is it a Repository or a DAO?
TL;DR;
This looks more like Repository to me; personally.
There is a good part of controversy between Repository and DAO among purists. Many developers use terms DAO and Repository interchangeably. I personally do not put myself deep in that debate. I prefer to focus on my application needs instead.
Following is very rough description of some of the patterns used in Data Access Layer:
Unit Of Work:
- Handle database connection and transactions.
- Additionally handle cache, batch queries, tracking etc.
- Please refer this answer.
Repository:
- May use UnitOfWork; not always.
- Not per table, it is per aggregate root.
- Returns Domain Object; NOT Object State (Entity/POCO).
- Please refer this answer. Also, this other answer for few more terms.
DAO (Data Access Objects):
- Tightly bound to database instead of Business Logic.
- Mostly 1:1 mapping with tables.
- Each action is transaction.
- Returns Object State (Entity/POCO).
CQRS (Command Query Responsibility Segregation):
- Use a different model to write (INSERT, UPDATE, DELETE) data than the model you use to read (SELECT) data.
- Write operations are covered under Command.
- Read operations are covered under Query.
- Each layer can be optimized independently for specific needs.
Query Object:
- Accept queries as an object in parameter of method.
Data Mapper:
- Map POCO/Entity classes with database row and vice versa.
- ORMs (Object Relational Mappers) are based on this pattern.
Active Record:
- Properties and Methods related to instance are in same class.
- Mapping happens in same class.
- Acts on single record.
Menu
428
