Object Relational persistence in. net

Introduction (background)

Among. NET developers, I believe most people have been in touch with or heard of Object Persistence frameworks (such as nhib.pdf ). I have used two data persistence solutions. One is to use attributes to modify fields/properties, and then the framework uses the transmitter mechanism to obtain metadata (metadata) and persist it, another solution is to put metadata in an external XML file, and then use the reflection mechanism to complete object persistence.

Pros and cons (COIN dual sides)

For the following reasons, I personally recommend external XML files:

1. Even ifSource codeIn this case, we can map to classes based on XML definitions for post-storage (useful when using third-party libraries ).
2. Ing data is not confused by class definitions.
3. When an object requires multiple persistence schemes, we can define multiple different ing files. At least she is more flexible and scalable.

In my opinion, these two solutions are inherently fragile. It does not have type safety or the type check during compilation to ensure the integrity and correctness of the ing.

Improved solution (upgrade solution)

Recently, I used the external storage XML ing file method to implement an object-relational persistence framework prototype. It provides CRUD (create, retrieve, update, delete) capabilities for business logic objects. I ensure that this scheme can be used for system. transaction to provide transcation (Transaction Processing) support.

In, you can see a class definition, a ing file, andCodeSegment, which is an employee class and an instance that saves it to the database. This implementation is similar to other existing implementation solutions. I use the new features in Asp.net 2.0 editing mode to add values to it:

I wrote a custom build provider that maps all files with the suffix ". Orm" under the app_code directory. This custom build provider can translate existing ing files and generate an encapsulation class for each ing file to ensure that only the defined operations can be used in the business logic object.

For example, if the ORM file only defines the insert and update operations in the ing definition, the encapsulation class page of The ing file only includes the insert and update methods. If the class name is not correctly spelled or a class has two identical ing definitions, the error exception will be broken during editing. If the developer modifies the definition in the ing file and saves the ing file, Visual Studio 2005 quickly identifies the change and immediately starts building to provide intelliisense support for the new method (for example ):

Demonstrate the sample code generated by the custom build provider for us in the background. In this way, vulnerable ing definitions in XML files are verified and secure code is generated during compilation. This greatly reduces the time spent in development and unit testing:

Improvements (Improvement)

This build provider can be further extended to support the validation of the existence of database stored procedures defined in the ing file, as well as the validation of the parameter correctness of the storage layer required, and so on...

Conclusion (conclusion)

I firmly believe that the support during editing will increase a lot of value for the existing object relational Persistence Solution and bring many new possibilities and opportunities.

 

PS:

Address: http://www.codeproject.com/aspnet/orm.asp

Code download: http://www.codeproject.com/aspnet/orm/ORM.zip