4 ms·

Agree re: methodology. There are really two problems in the model layer of a database-based app: - Moving data into and out of the database, the "Data Access L

Agree re: methodology. There are really two problems in the model layer of a database-based app: - Moving data into and out of the database, the "Data Access Layer" - How the model objects interact and behave once moved into memory, the "Domain Model"; this is pure OO and is amenable to fast, in-memory-only testing. Rails treats these two as a single layer. On a project I'm working on now, we separated them into two distinct layers, which allows 1-2ms test execution in the model layer. We do test persistence, and it takes some time, but we can be a lot sparser with these slow, heavy tests. In the end I think the choice of approach depends on how complex the domain model is. My domain has almost 100 objects arranged in various ways, putting us over the threshold where persistence should be treated as its own concern (vs. bundling it into the model). I suspect a lot of apps are better done via the Rails approach as it's much simpler, if slower to test.

grandalf 11y ago
> I suspect a lot of apps are better done via the Rails approach as it's much simpler, if slower to test. I have been inclined to agree with this, but lately have begun to wonder. I think the relational model (and document model) lead to the need for lots of manual traversal/management of the graph/hierarchy of a domain model. And, in an OOP sense, models have behavior (and of course state). But behavior involves mutating the state of one domain object and others, via their public API (behaviors). Yet most of the so-called behaviors are actually just adding/changing nodes/edges to the graph, which makes the model's main behavior data validation. So we have this elaborate, tightly-coupled system that pretty much only does data validation, but via the elaborate mechanism of object behavior and internal state. The typical test suite tests the propagation of this data through the system and verifies that the proper object state has been mutated/persisted, since the proper functioning of the system is easy to doubt.
- eldavido 11y ago
  Email me if you want to discuss this further. My email's in my profile. I came from using Rails to doing DDD-style C#/.NET development. It feels very "enterprise" but then, there are some very good lessons I've learned, one being how to write fast code-only unit tests.

grandalf 11y ago

> I suspect a lot of apps are better done via the Rails approach as it's much simpler, if slower to test. I have been inclined to agree with this, but lately have begun to wonder. I think the relational model (and document model) lead to the need for lots of manual traversal/management of the graph/hierarchy of a domain model. And, in an OOP sense, models have behavior (and of course state). But behavior involves mutating the state of one domain object and others, via their public API (behaviors). Yet most of the so-called behaviors are actually just adding/changing nodes/edges to the graph, which makes the model's main behavior data validation. So we have this elaborate, tightly-coupled system that pretty much only does data validation, but via the elaborate mechanism of object behavior and internal state. The typical test suite tests the propagation of this data through the system and verifies that the proper object state has been mutated/persisted, since the proper functioning of the system is easy to doubt.

eldavido 11y ago
Email me if you want to discuss this further. My email's in my profile. I came from using Rails to doing DDD-style C#/.NET development. It feels very "enterprise" but then, there are some very good lessons I've learned, one being how to write fast code-only unit tests.