Evolution of ORM and Repository Pattern
1 Row Data Gateway Pattern
2. Active Record Pattern
3. Table Data Gateway Pattern
4. Data Mappers
Non Repository Based Data Mappers
5.Repository Based Data Mappers
6. Many Patterns were done to make the 5 more OO. All these patterns are done on the top of Data Mapper + Repository pattern.
Query Objects, Indentity Map, MataDataORMMappings Tables, UOW, LINQ, Lazy Loading,
1- Whole this hell was done to make the Data Mapper more OO oriented. It makes Data Mappers more OO oriented in such a way that we are query and updating collection based DB in the memory.
2- they were done to push the nasty DB concerns behind the scene.
All were done to push the Dirty Transactions and concurrentcy and queries and DB Dirt out of OO API to access the DB.
3- Make OO API more performance and efficeitn and quick
4- Deal with the Negatives to of OO API. Bring the positives of DB World and reflect them in the OO API.
5- Further ORMs are supporting Conventions, Fluent APIs, Data Annotations, Code First Migrations to make the DDD, Onion, Clean and Hexagonal arch happen
New ORM or Repository should be
OO Focused
DDD focused
DDD focused mean Domain Model should drivde the DbSchema. As the OO Model evolves the DB Schema should evolve as well by CF Migrations.
Onion, Clean and Hex arch are on their mission to make all details plugins as we have done in the case of DB using the Data Mapper and Repostiory and other pattern around repository. Frameworks, MVC, CCCs, Infrastructure, Other Applications become plugins.
Further IOC/DI has made Layered ARch and Onion. Onion shape suit more to Layered ARch
Dependency Flow
Control Flow
I think it is overly excessive if we use ORM for CRUD and Bread work
Data Mappers based ADO.NET have knowlege of persisteance and DB. they are not persistence ignorant. They hve the knowledge of SQL, Transactions, Concurrentcy, Connections, Result set fetch, can be done easilty with Code Generttion. Whole junk can be avoided by Code genertion. We do not add so may layer of abstrations but rather use code generation. OO is Data Mapper is wild Craze and we have make it lot compilcated in order to just push DB out of Data Project.
Have DB in the Data Mapper vs. Clean Data Mapper
DB oriented Data Mapper should be acceptable in Small and Medium EA. It is OK
Code Generation vs. ORM + OO Data Mappers
1 Row Data Gateway Pattern
2. Active Record Pattern
3. Table Data Gateway Pattern
4. Data Mappers
Non Repository Based Data Mappers
5.Repository Based Data Mappers
6. Many Patterns were done to make the 5 more OO. All these patterns are done on the top of Data Mapper + Repository pattern.
Query Objects, Indentity Map, MataDataORMMappings Tables, UOW, LINQ, Lazy Loading,
1- Whole this hell was done to make the Data Mapper more OO oriented. It makes Data Mappers more OO oriented in such a way that we are query and updating collection based DB in the memory.
2- they were done to push the nasty DB concerns behind the scene.
All were done to push the Dirty Transactions and concurrentcy and queries and DB Dirt out of OO API to access the DB.
3- Make OO API more performance and efficeitn and quick
4- Deal with the Negatives to of OO API. Bring the positives of DB World and reflect them in the OO API.
5- Further ORMs are supporting Conventions, Fluent APIs, Data Annotations, Code First Migrations to make the DDD, Onion, Clean and Hexagonal arch happen
New ORM or Repository should be
OO Focused
DDD focused
DDD focused mean Domain Model should drivde the DbSchema. As the OO Model evolves the DB Schema should evolve as well by CF Migrations.
Onion, Clean and Hex arch are on their mission to make all details plugins as we have done in the case of DB using the Data Mapper and Repostiory and other pattern around repository. Frameworks, MVC, CCCs, Infrastructure, Other Applications become plugins.
Further IOC/DI has made Layered ARch and Onion. Onion shape suit more to Layered ARch
Dependency Flow
Control Flow
I think it is overly excessive if we use ORM for CRUD and Bread work
Data Mappers based ADO.NET have knowlege of persisteance and DB. they are not persistence ignorant. They hve the knowledge of SQL, Transactions, Concurrentcy, Connections, Result set fetch, can be done easilty with Code Generttion. Whole junk can be avoided by Code genertion. We do not add so may layer of abstrations but rather use code generation. OO is Data Mapper is wild Craze and we have make it lot compilcated in order to just push DB out of Data Project.
Have DB in the Data Mapper vs. Clean Data Mapper
DB oriented Data Mapper should be acceptable in Small and Medium EA. It is OK
Code Generation vs. ORM + OO Data Mappers
No comments:
Post a Comment