My feelings for nhibator (4): an amazing interceptor mechanism

I have talked about several aspects of nhib.pdf before, and I seem to complain a lot about it. But this time I want to talk about my feelings about interceptor, it's basically a good word. This does not necessarily mean how well interceptor is designed (in fact, it is quite troublesome to use), but it is also true that I think nhib.pdf is better than LINQ to SQL, in particular, another important aspect of Entity Framework-Because Entity Framework itself is no longer bad. More importantly, the interceptor mechanism allows me to implement the "ideal" data access function. Of course, it's just a bit of a bit. I plan to talk about the satisfactory "data access layer" design in detail later.

Interceptor is used to add an "interceptor" for sessions in Nhibernate (for example, datacontext in LINQ to SQL). This interceptor will capture what happens in each stage of the session, they also have the opportunity to access the data they involve. For example:

• Onload: objects loaded by the current session
• Ondelete: Objects deleted by the current session
• Onsave: Objects saved by the session
• Postflush: the current session flush has been completed.

For more information about the interceptor function, the nhib.pdf document is just a document. For more information, see the hibernate API description. Since interceptor can record all objects passed by the session, it can do a lot of things. For example, a "log record" or "audit (Audit)" that has been overwritten, but it seems that few people actually use it in the data access function. After I learned about interceptor, I was very excited because someone finally paved the way for the functions I wanted to implement. This function is "combined with other data access mechanisms ".

Speaking of the data access layer, you must know that it is responsible for "reading and writing data from data sources ". For a long time, this data source is basically a relational database, regardless of the commercial SQL Server, Oracle, open-source MySQL, PostgreSQL, and so on. So someone proposed an SQL-object ing tool such as sqlhelper, data access block, and an auxiliary database reading tool such as ibatis (I don't think it's an ORM) and ORM frameworks such as nhib.pdf and LINQ to SQL. However, no matter what the tool is, no matter how it is accessed, the data access layer does nothing more than SQL, SQL, and SQL, and then converts the obtained dataset to an object in memory.

However, in today's era, the data source at the data access layer is far more than that. For example, Xu Qianjin introduced the data access layer function of the mobile phone home on his blog, one of which is:

This is a typical data access layer function. In addition to accessing relational databases, it may also need to access asynchronous message queues (such as MSMQ and activemq) and k/V Storage (such as memcached, tokyo Cabinet) or other document-type databases (such as MongoDB and couchdb ). That is to say, when we store data in a relational database, we may need to add an asynchronous message or synchronize it to other storage methods-and interceptor provides us with this possibility.

For example, this is a articleinterceptor structure:

 Public class  Articleinterceptor : Emptyinterceptor { Public override bool Onload (Object Entity, Object ID ,...){ VaR Article = entity As  Article ; If (Article = Null ) Return false ; // Write down all loaded articleids  Return false ;} Public override void Ondelete ( Object Entity, Object ID ,...){ VaR Article = entity As  Article ; If (Article = Null ) Return ; // Write down all deleted articleids } Public override void Postflush ( Icollection Entities ){ Foreach ( VaR Article In Entities. oftype <Article > ()){ // Compare and submit the modified, created, or deleted Articles to the Lucene Index }}  }

One of the advantages of nhib.pdf is the "Automatic Tracking" Object status, and interceptor also gives us the opportunity to plug in. With the above articleinterceptor, we can know which article objects have been modified in the session and synchronize them to Lucene indexes after the flush operation. Of course, this is just an example (in fact, Lucene indexes can only be written by a single thread). The specific situation needs to be changed according to their own needs. The more critical issue may be "transactions.

Postflush is called after the session flush operation is completed, but the current database transaction may not be completed at this time-this may be becauseProgramWhen using Nhibernate, we chose the external transaction control method, which may be cross-session. Therefore, if an update is like an external data source, it will not "get involved" in the current database transaction (it may not be possible or it may intentionally avoid distributed transactions ), therefore, if the write is completed in the postflush operation, can the update of the external data source be canceled together after the current transaction is rolled back?

However, this should not be a problem for programmers. For example, we can "record" the content to be updated after postflush, and write the content to the external data source only when the entire transaction is successful. In short, it should be determined based on the needs of different projects.

With the interceptor of nhib.pdf, we can do more in this aspect.Article. For example, we can put the content data of the article object into the k/V Storage, which can reduce the size of each row of the table in the relational database and improve the performance. Then, when loading the article object, we can read the content data of the article back from the k/V storage in the interceptor onload method.

Therefore, in my opinion, we can use Interceptor to create an object-any-mapping tool using the Nhibernate ORM framework, and map objects to the "any" storage method. About two months ago, I thought, what should I do if I really want to build an OAM framework like this?

However, I thought about giving up. This is because the framework is too complex. In my opinion, if you use a common OAM framework, you must be able to support multiple data sources and divide an object into multiple parts and put them into different data sources. You can also select a query method based on the characteristics of different data sources during query (for example, use full-text search to go to Lucene, and obtain data based on the ID is stored in K/V, others may be relational databases or document databases)-or even automatically obtain data from different data sources and perform join operations in the memory.

These are the real functions required in the actual development process, but an ORM framework like nhib.pdf is already so complicated. How is the OAM "feasibility ...... I think everyone will think about the results. Although hibernate already has some general frameworks, such as hiberante search integrated with Lucene, Hibernate sharding can support automatic database division, but is their "versatility" really as high as hibernate? I doubt this.

Therefore, for the moment, I think the most feasible method is probably the data access layer based on a powerful ORM framework like nhib.pdf, as for the internal "at which time to choose the data operation method", the data access layer should follow its own needs. Because "common" is not required, such a data access layer can be much simpler.

Because of the continuous emergence of storage methods, it has become an important topic to select a suitable storage method for appropriate operations. Therefore, the construction of the data access layer is becoming more and more important, it is not just a boring CRUD operation-it is not a complicated logic for some projects, and its "business logic layer" will appear very thin. How is your data access layer built? Can you share your experience in this area?

In future articles, I will expand more.

Related Articles

• My feelings about nhib.pdf (1): misunderstandings about delayed Loading Methods
• My feelings about nhib.pdf (2): Why is virtual everywhere?
• My feelings about nhib.pdf (3): some embarrassing collections support
• My feelings for nhibator (4): an amazing interceptor mechanism