How Domain-Driver Works

Domain-Driver is designed around the realization that it is more importance to program against a clear persistence behavior than a specific storage technology. By prioritizing behavior over technology, we allow developers to utilize new technologies by adapting their behavior to a common interface.

The behavior we have chosen to program against is explicit Create-Read-Update-Delete (CRUD) behavior (as opposed to implicit updates via calls to save changes), since all persistence technologies can be adapted to function in this manner. Our repository interface provides this functionality for pure Plain-Old-CLR-Objects (POCOs), so from the repository outwards the client code interacts with pure objects.

Beneath the repository the actual persistence functionality is accomplished using a technology-specific storage manager. The storage managers provided in the framework generically adapt the specific technology at hand to the CRUD behavior. Any user of the Domain-Driver framework can implement new storage managers to work with technologies beyond those provided within this release.

The simplest storage manager avaiable is the TransientStorageManager, which adapts a standard .NET dictionary to behave as a in-memory database, providing CRUD functionality. This storage manager can be critically important in prototyping and unit testing.

Specifically, the TransientStorageManager gives developers the ability to implement fully functional domain models and GUIs without ever writing any persistence code. By doing so, developers can present their clients with functional prototypes before investing significant time and effort in implementing true persistence for their models.

Also, the TransientStorageManager allows developers to write verifiable unit tests that all other technology-specific storage implementations must also pass. In this manner, unit testing becomes quicker, more convenient, and more effective.

Last edited Apr 11, 2011 at 7:23 AM by ryanse, version 3

Comments

No comments yet.