Timeline for Should ORM data access methods be wrapped or used directly?
Current License: CC BY-SA 3.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 17, 2018 at 9:52 | comment | added | Rafał Łużyński | sure, you do the mapping in repository, but not in DjangoORM, because it has no mapper and Unit of Work. | |
| Oct 17, 2018 at 9:41 | comment | added | David Jiménez Martínez | @RafałŁużyński to return Aggregates from django models what I do is to have my own Aggregate version and then let the repository do the mapping. E.g. ProductDjangoModel is returned by the ORM and then I map it into a Product entity from the repository. The product entity makes more sense in the business logic. | |
| Nov 10, 2014 at 15:37 | history | edited | Tulains Córdova | CC BY-SA 3.0 | added 1 character in body |
| Aug 12, 2014 at 18:42 | comment | added | Robert Harvey | Ah, I see what you're saying. stackoverflow.com/a/1958722 | |
| Aug 12, 2014 at 18:35 | comment | added | Rafał Łużyński | ORM is returning it's own objects, how can I make Django ORM/hibernate/doctrine return aggregate roots? | |
| Aug 12, 2014 at 18:28 | comment | added | Robert Harvey | Why not just let the ORM do that? | |
| Aug 12, 2014 at 18:26 | comment | added | Rafał Łużyński | What do you mean, that they "do something"? In ddd it just return aggregate roots, business logic should be outside of repository according to books. | |
| Aug 12, 2014 at 17:26 | comment | added | Robert Harvey | An example would make your answer a better one. From my point of view, the most valuable benefit of a Repository abstraction or service layer is that you expose methods that do something, rather than simple pass-through methods that merely return business objects. | |
| Aug 12, 2014 at 11:04 | review | First posts | |||
| Aug 12, 2014 at 13:22 | |||||
| Aug 12, 2014 at 11:01 | history | answered | Rafał Łużyński | CC BY-SA 3.0 |