Jive forum and Spring framework

No new technology is born out of thin air, and Its Sprout or embryo is always more or less apparent in previous technologies. Jive forum is a design-oriented application that everyone studies with great concentration. Program .

Jive and spring are J2EE Web Systems Composed of JavaBeans. As an early successful design case, jive has become a popular architecture for most pure ans systems, and spring is no exception.

In addition to a Web-layer application framework, the Spring framework also provides interfaces for accessing the EJB layer and direct JDBC/ORM operations. The main charm of the Spring framework is that the IOC mode and AOP are used to implement the general functions of the jive system, so that the pure JavaBeans architecture design such as jive can be reused in other systems.

If you feel deeply about the design concept of jive, but you cannot reuse it, the Spring framework has already helped you implement it.

At the same time, it should be noted that the Spring framework is similar to the "hodgedge". It contains many J2EE application tools, such as calling EJB. Its MVC and Struts JSF are also competing, for pure IOC and AOP design, the Spring framework is also a very heavy (heavy, weight) framework. The Spring framework is complex. If you want to replace EJB with spring, you will undoubtedly float the handler.

Linking the jive forum with the Spring framework will help more programmers who understand the design pattern quickly grasp the latest design trend, rather than a sudden forced acceptance. If you have a good research on jive, you will find that the Spring framework is a more general improvement of jive design.

In jive, forumfactory is the entry point and breakthrough point of the entire system. Jive uses forumfactory to control the entire system in a factory mode. The advantage of this is that it is easy to control the system's JavaBeans, for example, the client can create a forum or access a forum through forumfactory, but is there access permission? For example:

Jive uses forumfactory to direct such access to the corresponding proxy class, such as the forumfactoryproxy class, and uses the proxy mode to control access to these classes. This is a major use of the proxy mode, but studying the proxy mode of jive will find that it is very trivial to implement a proxy class for each class. Is there a more elegant way? Of course, dynamic proxy is used.

The Spring framework basically abstracts the above design. The Spring framework manages all JavaBeans Based on the Bean Factory mechanism at the same entrance. The difference is that beanfactory can manage the JavaBeans of all applications, the user only needs to tell beanfactory through the configuration file of their own JavaBeans, then beanfactory will load these JavaBeans, for example:

<Beans> <bean id = "examplebean" class = "eg. examplebean"/> <bean id = "anotherexample" class = "eg. examplebeantwo"/> </beans>

In jive, forumfactory implements dbforumfactory to load jive's own JavaBeans through the factory, as shown below:CodeDbforumfactory triggers a series of functions in the background, which is vertical, while the return New forumfactoryproxy statement is similar to attracting a plane, which implements permission access and other functions from a horizontal aspect:

Private Static string classname = "com. jivesoftware. forum. database. dbforumfactory "; public static forumfactory getinstance (authorization) {// if no valid authorization passed in, return null. if (authorization = NULL) {return NULL;} // The Singleton single-State mode if (factory = NULL) {synchronized (initlock) {If (factory = NULL) is used below) {...... try {// dynamic reprint class C = Class. forname (classname); factory = (forumfactory) C. newinstance () ;}catch (exception e) {return NULL ;}}// now, return proxy. used to restrict access to Forum. Return new forumfactoryproxy (authorization, factory, factory. getpermissions (authorization ));}

Since the spring framework loads all classes through a bean factory, how is it loaded? The IOC mode is used, that is, the dependent injection mode. Before meArticleIn the "IOC mode", I compared the similarities and differences between the injection object implementation in the factory mode and the IOC mode. IOC is more decoupled from the relationship between the caller and the called than the factory mode, the IOC mode does not need to involve the specific implementation of the called in the caller code.

The Spring framework can not only inject the ans defined by the app to its own containers (that is, create them), but also assign values to these JavaBeans using the set method.

Once Bean Factory is running in charge of these activated objects, spring uses the AOP method to provide these JavaBeans with the implementation of common functions such as permission access and transaction lock from a horizontal plane, this implementation is based on the dynamic proxy mode, while dynamic proxy is a way of Implementing AOP.

As mentioned above, in jive, permission access is implemented in proxy mode, which is more concise and abstract than the proxy mode. Dynamic proxy makes it unnecessary for the caller to specify the proxy class of the caller, this is the essence of the dynamic proxy mode.

The advantage of dynamic proxy can also be reflected in another sentence: Dynamic proxy intercepts the caller's calls to the called, which is exactly in line with the AOP interceptor function, it provides a possibility for AOP implementation.

The Spring framework uses dynamic proxy to implement AOP. It intercepts external calls to objects managed by Bean Factory through the dynamic proxy mechanism. For example:

The above just roughly deconstruct the spring architecture. In this architecture, the Spring framework also carries many other features, such as web MVC, Dao JDBC, Dao Orm, and remote, the latter is similar to the EJB method call framework I designed.

In short, spring is indeed a perfect application of IOC and AOP. IOC is used to load JavaBeans and create these objects. AOP is used to intercept the use of these objects, which is the inevitable classic method of framework design.