EntityFramework's field-driven design Practice (ix): Storage realization: In-depth articles

As early as years ago in the Csai blog published an article: "The realization of warehousing: basic article." Struggling day and night in between work and life, has not been able to find time to continue to explore the implementation of warehousing details, but also a lot of attention to entityframework and domain-driven design of friends are disappointed.

Gossip is not much said, and now continue to consider how to let warehousing operations in the same things in the context of the process. One of the purposes of DDD, which is to introduce warehousing mode, is to make the domain model more "pure" through the technical details of the persistence of hidden objects in storage. This shows that the implementation of warehousing is required by the infrastructure Layer component support, performance for the database operation. In the traditional relational database operation, transaction processing is an important concept, although in some large-scale projects, transaction processing can reduce the efficiency, but it guarantees the integrity of the data. Relational database is still the mainstream of data persistence mechanism, and the implementation of transaction processing is necessary.

In order to cater to the warehousing mode, it is necessary to make some adjustments to the classic ObjectContext usage mode. For example, we could have used the use (entitiescontainer EC = new Entitiescontainer ()) statement very simply to define the scope of the LINQ to Entities operation, and use the ObjectContext SaveChanges member method to commit the transaction, and in the introduction of the implementation of the warehousing, you can not continue to use this classic method. It makes entityframework look strange and far-fetched, and I believe many netizens will criticize my approach because I complicate the problem.

In fact, this should be a different point of attention. The developers who pay attention to entityframework naturally feel that the classic invocation is simple and straightforward, but from the perspective of DDD? can only focus on warehousing, and the entityframework as a storage technology selection (of course, from the ddd point of view, we can not choose EntityFramework, and to choose other technology). So this paper aside EntityFramework, continue on the basis of above, discuss the realization of warehousing.

As mentioned earlier, the implementation of warehousing needs to consider transaction processing, and based on the experience of DDD, for each aggregation root, need to have a storage for its persistence and object reassembly operations. To this end, my idea is that warehousing operations "defined" in a transaction context (contexts), the storage instance is obtained by the contextual, which is somewhat like the entityframework ObjectContext and entityobject relationship. Since warehousing is derived from the transaction context, it knows which transaction contexts are currently in. The transaction context I define is as follows:

Transaction context

public　interface　IRepositoryTransactionContext　:　IDisposable
{
　　 IRepository<TEntity>　GetRepository<TEntity>()
　　　　 where　TEntity　:　EntityObject,　IAggregateRoot;
　　 void　BeginTransaction();
　　 void　Commit();
　　 void　Rollback();
}


The third line of code above defines an interface method, the main function of which is to return a warehouse instance for the specified aggregate root entity. The remaining three lines of code are obvious, which is the standard transaction operation: Starting the transaction, committing the transaction, and rolling back the transaction.