Timeline for To Repository Or Not To Repository
Current License: CC BY-SA 3.0
3 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 6, 2014 at 13:53 | comment | added | MikeSW | About adding a new way to query an aggregate root or any entity, that's why CQRS appeared. Personally, I keep the Repository for domain purposes and use query handlers for actual querying. And those handlers are very tightly coupled to the db and ofc very efficient at what they do. | |
| May 6, 2014 at 13:50 | comment | added | MikeSW | The point of the repository is to decouple app from persistence and there's no complexity involved. And I change the persistence details at least once, because the db access is the last thing I code, until that point I'm using in memory repos. Besides, there is a very subtle trap when you're using a persistence detail directly. Your business objects will tend to be designed to be compatible with it, instead of agnostic. And that's because a rich, properly encapsulated entity can't be directly restored from any storage (except memory) without (some ugly) workarounds | |
| May 1, 2014 at 7:14 | history | answered | Euphoric | CC BY-SA 3.0 |