Using the Domain Objects Persistence Pattern in .NET
Domain application objects are usually central to the entire application and used by most subsystems. They represent the core data and business validation rules; therefore, good domain object design is critical for robust, high performing, yet flexible applications.
by Iqbal M. Khan
August 24, 2005
hen developing object-oriented applications that use relational databases, creating a domain object design that's consistent with the database design makes applications easier to understand, because domain objects typically represent real-life "entities" and their relationships with each other. Therefore, in many situations, the domain objects are "mapped" to the relational database tables and relationships between tables. However, it is very easy to get this mapping wrong and end up with an undesirable domain object design. A good design for domain objects requires developers to have a solid understanding of object oriented and relational fundamentals.
The Domain Objects Persistence pattern attempts to provide a mapping to relational databases that decouples the domain objects from the persistence logic. In this pattern, the domain objects themselves are unaware of the persistence mechanism, because the dependency is only one-way (from persistence objects to domain objects). This simplifies the domain objects' design and makes them easier to understand. It also hides the persistence objects from other subsystems in the application that are using the domain objects. Even better, the pattern also works in distributed systems where only the domain objects are passed around, thus insulating the application from exposing the persistance mechanism to outside code. This article shows you how to incorporate the Factory pattern into the Domain Objects Persistence pattern to help decouple domain objects and persistence logic.
It's quick, easy and you get access to all the articles on DevX.
This registration/login is to allow you to read articles on devx.com. Already a member?
To become a member of DevX.com create your Member Profile by completing the form below. Membership is free!
hen developing object-oriented applications that use relational databases, creating a domain object design that's consistent with the database design makes applications easier to understand, because domain objects typically represent real-life "entities" and their relationships with each other. Therefore, in many situations, the domain objects are "mapped" to the relational database tables and relationships between tables. However, it is very easy to get this mapping wrong and end up with an undesirable domain object design. A good design for domain objects requires developers to have a solid understanding of object oriented and relational fundamentals.
