Metadata
- Author:: 37signals Dev
- Full Title:: Active Record, Nice and Blended
- Category:: 🗞️Articles
- URL:: https://dev.37signals.com/active-record-nice-and-blended/
- Finished date:: 2022-12-21
Highlights
- isolate database access on its own layer to keep the domain model persistence-free. For example repositories, Data Mappers or DAOs (Data Access Objects) (View Highlight)
- Even Fowler mentions that the pattern is a good choice for domain logic that isn’t too complex. It’s our experience, however, that Rails’ Active Record keeps code elegant and maintainable in large and complex codebases (View Highlight)
- you don’t see a cognitive jump between “business logic” and “persistence duties”. To me, this trait is a game-changer. (View Highlight)
- Fowler argues that:
If your business logic is complex, you’ll soon want to use your object’s direct relationships, collections, inheritance, and so forth. These don’t map easily onto Active Record, and adding them piecemeal gets very messy. Rails’ Active Record offers answers for those and more. To enum a few: associations, single table inheritance, serialized attributes or delegated types. (View Highlight)
- building rich domain models becomes harder. If domain models are free of persistence concerns, how can they implement business logic that needs to access the database? In DDD, for example, the answer is adding additional domain-level elements such as repositories and aggregates. Now you have three elements to coordinate, with plain domain entities knowing nothing about persistence. How do they access each other? How do they collaborate? (View Highlight)
- It is not surprising that, ironically, many implementations that aim to embrace the best design practices end up suffering the anemic domain model problem, where most entities are mere data holders without behavior. (View Highlight)
- My point of view is that if the ORM perfectly blends with the host language, and if it comes with good answers for persisting your object models, and if it offers good encapsulation mechanisms, then the original question gets restated (View Highlight)
Metadata
- Author: 37signals Dev
- Full Title:: Active Record, Nice and Blended
- Category:: 🗞️Articles
- URL:: https://dev.37signals.com/active-record-nice-and-blended/
- Finished date:: 2023-01-25
Highlights
- isolate database access on its own layer to keep the domain model persistence-free. For example repositories, Data Mappers or DAOs (Data Access Objects) (View Highlight)
- Even Fowler mentions that the pattern is a good choice for domain logic that isn’t too complex. It’s our experience, however, that Rails’ Active Record keeps code elegant and maintainable in large and complex codebases (View Highlight)
- you don’t see a cognitive jump between “business logic” and “persistence duties”. To me, this trait is a game-changer. (View Highlight)
- Fowler argues that:
If your business logic is complex, you’ll soon want to use your object’s direct relationships, collections, inheritance, and so forth. These don’t map easily onto Active Record, and adding them piecemeal gets very messy. Rails’ Active Record offers answers for those and more. To enum a few: associations, single table inheritance, serialized attributes or delegated types. (View Highlight)
- building rich domain models becomes harder. If domain models are free of persistence concerns, how can they implement business logic that needs to access the database? In DDD, for example, the answer is adding additional domain-level elements such as repositories and aggregates. Now you have three elements to coordinate, with plain domain entities knowing nothing about persistence. How do they access each other? How do they collaborate? (View Highlight)
- It is not surprising that, ironically, many implementations that aim to embrace the best design practices end up suffering the anemic domain model problem, where most entities are mere data holders without behavior. (View Highlight)
- My point of view is that if the ORM perfectly blends with the host language, and if it comes with good answers for persisting your object models, and if it offers good encapsulation mechanisms, then the original question gets restated (View Highlight)