Using the domain object persistence mode in. net

Domain Application objects are usually the center of the entire application and are used by many subsystems. They represent core data and business verification rules; therefore, a good domain object design is critical to strong, high-performance, and flexible applications.

When developing object-oriented applications that use relational databases, establishing a domain object design consistent with the database design makes it easier for applications to understand. This is because, in typical cases, domain objects represent real "entities" and their relationships. Therefore, in many cases, domain objects are "mapped" to the relationship between relational database tables and tables. However, this ing is very error-prone and ends with an undesired domain object design. The good design of domain objects requires developers to have a deep understanding of the basic principles of object-oriented and relational.

The domain objects persistence pattern attempts to provide a ing relationship to the relational database, removing the coupling relationship between the domain object and the continuity logic. In this mode, the domain object itself does not know the persistence mechanism, because its dependency is in a single direction (from the Persistent Object to the domain object ). This simplifies the design of domain objects and makes them easier to understand. It also hides persistent objects from subsystems in the application that use domain objects. Better yet, this mode can be used in distributed systems. In this case, only domain objects are transmitted everywhere, so that the application does not need to expose the persistence mechanism to external code. This article demonstrates how to make the factory mode and the domain object persistence mode work together to help the domain object and the persistence logic uncouple.

Definition problems

Domain objects are the hub of all applications. They capture the core data model of the database and the business rules applied to the data. In typical cases, most subsystems of an application depend on these generic domain objects-this means that the closer the ing of the domain objects to the database outline, the easier it is for application developers to understand and use them, because they represent the real "entity" and "relationship" in the database ".

If the domain object is not separated from other parts of the application, you usually have to copy the continuous code to many locations. Similarly, if the domain object is not separated from the persistent code, you may encounter a situation where any subsystem that uses the domain object must know and rely on the Persistent Object. Any changes to the persistent object will inevitably affect the entire application. Therefore, it is difficult to design a domain object that is not separated from the application and persistent code.

Define a solution

One way to achieve the above goal is to separate the domain objects into an independent sub-system, so that other parts of the application need domain data before using them. In addition, you must separate the domain object from the persistent code. On the one hand, this double separation avoids code duplication; on the other hand, it hides the persistent details of the domain object and establishes a flexible design that is easier to modify. No matter the data comes from relational databases, XML files, flat files, active directories/ldap, or any other data source, domain objects and other parts of the application are completely unaffected.

In the process of separating the continuity logic and the domain object, you must ensure that the domain object does not depend on the continuity code. This operation allows you to expose domain objects to areas where you do not want to expose persistent code.

Example

The following C # example uses the customer object of the northwind Sample Database, which is mapped to the customer table of the database.

Public Class Customer { // Private Data Member String _ customerid; String _ companyName; String _ contactname; String _ contactTitle; Public Customer (){} // Attributes of the Customer object Public String CustomerId { Get {return _ customerId ;} Set {_ customerId = value ;} } Public String CompanyName { Get {return _ companyName ;} Set {_ companyName = value ;} } Public String ContactName { Get {return _ contactName ;} Set {_ contactName = value ;} } Public String ContactTitle { Get {return _ contactTitle ;} Set {_ contactTitle = value ;} } } Public interface ICustomerFactory { // Standard transaction Method for Single Row Operations Void Load (Customer cust ); Void Insert (Customer cust ); Void Update (Customer cust ); Void Delete (Customer cust ); // Return the query method of the Set ArrayList FindCustomersByState (String state ); } Public class CustomerFactory: ICustomerFactory { // Standard transaction Method for Single Row Operations Void Load (Customer cust) {/* Implement here */} Void Insert (Customer cust) {/* Implement here */} Void Update (Customer cust) {/* Implement here */} Void Delete (Customer cust) {/* Implement here */} // Return the query method of the Set ArrayList FindCustomersByState (String state ){ /* Here is the implementation code */ } }

The following example demonstrates how the client uses this code.

Public class NorthwindApp { Static void Main (string [] args ){ Customer cust = new Customer (); CustomerFactory custFactory = new CustomerFactory (); // Load the client from the Northwind database Cust. CustomerId = "ALFKI "; CustFactory. load (cust ); // Pass the Customer object FooBar (cust ); // CustList is the list of Customer objects ArrayList custList = custFactory. FindCustomersByState ("CA "); } }

In the above Code, the load method loads the customer object from the database according to customerid (the application can pass this value to any subsystem without exposing the persistent code. Similarly, if you load the array list of the customer object, you can also pass the array list, and there is no continuous code dependency.

Using the domain object persistence mode to separate the persistent code and customer object makes the customer object more object-oriented and easier to understand, because its object model is closer to the data model in the database. In addition, this separation allows you to pass the customer to different parts of the application (or even to distributed applications through. Net remoting) without exposing continuous code.