Summary of SSH and Oracle

Differences between struts1 and struts2:

1) Comparison of Action Implementation classes: struts 1 requires action classes to inherit an abstract base class; a specific problem of struts 1 is the use of abstract class programming rather than interfaces. Struts 2 Action class can implement an action interface or other interfaces to make optional and customized services possible. Struts 2 provides an actionsupport base class to implement common interfaces. Even if the action interface is not required, only one pojo class containing the execute method can be used as the action of struts 2.

2) Comparison of the thread mode: struts 1 action is a singleton mode and must be thread-safe, because only one instance of action is used to process all requests. The Singleton policy limits what struts 1 action can do and requires caution during development. Action resources must be thread-safe or synchronous. Struts 2 action objects generate an instance for each request, so there is no thread security problem.

3) servlet dependency comparison: struts 1 action depends on servlet API, because the execute method of struts 1 action includes the httpservletrequest and httpservletresponse methods. Struts 2 Action no longer depends on the servlet API, allowing the action to run out of the Web Container, thus reducing the difficulty of testing the action. Of course, if action needs to directly access the httpservletrequest and httpservletresponse parameters, Struts 2 action can still access them. However, most of the time, actions do not need to directly access httpservetrequest and httpservletresponse, thus giving developers more flexible choices.

4) Comparison of testability: a major problem in testing struts 1 action is that the execute method depends on the servlet API, which makes the test of action dependent on the Web container. To test the action of struts 1 from a Web Container, you must use a third-party Extension: struts testcase, which contains a series of mock objects (simulating the httpservetrequest and httpservletresponse objects ), in this way, you can test the action class of struts 1 from the Web container. Struts 2 action can be tested by initializing, setting properties, and calling methods.

5) Comparison of encapsulated request parameters: struts 1 uses the actionform object to encapsulate the user's request parameters. All actionforms must inherit a base class: actionform. Normal JavaBean cannot be used as an actionform. Therefore, developers must create a large number of actionform classes to encapsulate user request parameters. Although struts 1 provides dynamic actionform to simplify the development of actionform, it still needs to define actionform in the configuration file; struts 2 uses the Action property directly to encapsulate the user request attribute, this avoids the hassle of developers developing a large number of actionform classes. In fact, these attributes can also be rich object types that contain sub-attributes. If developers still miss struts
1. The actionform mode. Struts 2 provides the modeldriven mode, which allows developers to use a separate model object to encapsulate user request parameters. However, this model object does not need to inherit any struts 2 base classes, is a pojo, which reduces code pollution.

6) Expression Language Comparison: struts 1 integrates jstl, so jstl can be used. This expression language provides basic object graph traversal, but does not have a strong function in support of set and index attributes. Struts 2 can use jstl, however, it integrates a more powerful and flexible Expression Language: ognl (object graph notation language). Therefore, the expression language function in struts 2 is more powerful.

7)-Comparison of binding values to views: struts 1 binds objects to view pages using the standard JSP mechanism; struts 2 uses the valuestack technology to enable the tag library to access values, you do not need to bind the object with the view page.

8) Comparison of type conversion: the struts 1 actionform attribute is usually of the string type. Struts 1 uses commons-beanutils for type conversion. One converter for each class is not configurable. Struts 2 uses ognl for type conversion and supports conversion between basic data types and common objects.

9) data verification comparison: struts 1 supports manual verification in the actionform override validate method, or data verification by integrating the commons alidator framework. Struts 2 supports validation by rewriting the validate method, and also supports validation by integrating the xwork verification framework.

10) Comparison of Action execution control: struts 1 supports a request processing (the concept of lifecycle) for each module, but all actions in the module must share the same lifecycle. Struts 2 supports creating different lifecycles for each action through the interceptor stacks. Developers can create corresponding stacks as needed and use them with different actions.

11) Capture input: struts1 uses the actionform object to capture the input. All actionforms must inherit a base class. Because other JavaBean cannot be used as an actionform, developers often create redundant class capture inputs. Dynamic beans (dynabeans) can be used as an option to create a traditional actionform. However, developers may re-describe (create) the existing JavaBean (which will still lead to redundant JavaBean ). Struts 2 directly uses the action attribute as the INPUT attribute, eliminating the need for the second input object. The INPUT attribute may be a rich object type with its own (sub) attribute. The action attribute can be
Access taglibs on the web page. Struts2 also supports the actionform mode. Rich object type, including business objects, which can be used as input/output objects. This modeldriven feature simplifies taglib's reference to pojo input objects.

 

 

Differences between Oracle functions and stored procedures:

1. The difference between return values. A function has one return value, while a stored procedure returns a value through a parameter. There may be multiple or none
2. Differences in calling. A function can be called directly in a query statement, and a stored procedure must be called independently.
A function is generally used to calculate and return a computing result, while a stored procedure is generally used to perform specific data operations (such as modifying, inserting a database table, or executing some DDL statements)

 

Differences between is and as in Oracle stored procedures:

There is no difference between a stored procedure (Procedure) and a function (function). In a view, only as can be used, but is cannot be used. In cursor) can only use is, cannot use.

Hibernate Loading Mechanism

Orm frameworks such as Hibernate introduce the concepts of Eagar fetching and lazy fetching. If it is set to instant loading, email is automatically loaded when the person is loaded. If it is set to delayed loading, email is not loaded when the person is loaded. Instead, an SQL statement is executed when the person. getemails () is called for the first time.

Delayed loading: the real-time loading policy applies to all object relationships, such as one-to-many, one-to-one, and many-to-many.

 

Three delayed loading methods:

The delayed loading mechanism is proposed to avoid unnecessary performance overhead. The so-called delayed loading means that data loading is performed only when data is actually needed. Hibernate provides delayed loading of object objects and delayed loading of collections, and delayed loading of attributes in hibernate3. Next we will introduce the details of these types of delayed loading.

A. Delayed loading of object:

To use delayed loading for object objects, you must configure the object ing configuration file as follows:

<Hibernate-mapping>

<Class name = "com. Neusoft. entity. User" table = "user" lazy = "true">

......

</Class>

</Hibernate-mapping>

You can enable the delayed loading feature of an object by setting the lazy attribute of the class to true. If we run the following code:

User user = (User) Session. Load (user. Class, "1"); (1)

System. Out. println (user. getname (); (2)

When running at (1), Hibernate does not initiate data query. If we use some debugging tools (such as jbuilder2005's debug tool ), observe the memory snapshot of the user object. We are surprised to find that the returned user $ enhancerbycglib $ bede8986 type object and its attribute is null. What is the problem? I still remember that the session. Load () method previously mentioned will return the proxy class Object of the object. Here, the returned object type is the proxy class Object of the user object. In hibernate, cglib is used to dynamically construct the proxy class object of a target object, and the proxy class object contains all the attributes and methods of the target object, all attributes are assigned null values. Whether the values get attribute is null. If it is not null, The getname method of the target object is called. If it is null, a database query is initiated to generate an SQL statement similar to this: select
* From user where id+'1'then to query data, construct the target object, and assign the value to the cglib?calback_0.tar get attribute.

In this way, through an intermediate proxy object, Hibernate achieves object loading delay. Only when a user initiates an action to obtain object attributes can the user initiate a database query operation. Therefore, the delayed loading of objects is completed through the intermediate proxy class, so only session is available. the load () method uses the object to delay loading, because only the session. the load () method returns the proxy class Object of the object class.

B. Delayed loading of Collection types:

In the delayed Loading Mechanism of hibernate, it is of the most significant significance for the application of the set type, because it may greatly improve the performance, so hibernate has made a lot of efforts, this includes the independent implementation of JDK collection. In one-to-Multiple Association, the Set set defined to hold the associated object is not Java. util. set type or its subtype, but net. SF. hibernate. collection. set type. hibernate implements delayed loading of set types by using custom collection classes. To use delayed loading for the collection type, we must configure the related section of our object class as follows:

<Hibernate-mapping>

<Class name = "com. Neusoft. entity. User" table = "user">

.....

<Set name = "addresses" table = "address" lazy = "true" inverse = "true">

<Key column = "user_id"/>

<One-to-define class = "com. Neusoft. entity. arrderss"/>

</Set>

</Class>

</Hibernate-mapping>

Set the lazy attribute of the <set> element to true to enable the delayed loading feature of the set type. Let's look at the following code:

User user = (User) Session. Load (user. Class, "1 ");

Collection addset = user. getaddresses (); (1)

Iterator it = addset. iterator (); (2)

While (it. hasnext ()){

Address = (Address) it. Next ();

System. Out. println (address. getaddress ());

}

When the program is executed at (1), no query is initiated for the associated data to load the associated data. Only when the program runs at (2, the real data read operation starts. At this time, Hibernate searches for object objects that meet the condition based on the Qualified Data Index in the cache.

Here we introduce a new concept-Data Index. Next we will first take a look at what is data index. In hibernate, the set type is cached in two parts. First, the IDs of all objects in the set are cached, and then the object IDs are cached, it is the so-called data index. When you look for a data index, if the corresponding data index is not found, a select SQL statement is executed to obtain Qualified Data and construct a collection of Entity objects and data indexes, then return the collection of object objects and include the object objects and data indexes in the cache of hibernate. On the other hand, if the corresponding data index is found, the ID list is retrieved from the data index, and the corresponding entity is searched in the cache based on the ID. If it is found, it is returned from the cache, if not, select
SQL query. Here we can see another problem, which may affect the performance. This is a cache policy of the collection type. If we configure the collection type as follows:

<Hibernate-mapping>

<Class name = "com. Neusoft. entity. User" table = "user">

.....

<Set name = "addresses" table = "address" lazy = "true" inverse = "true">

<Cache Usage = "read-only"/>

<Key column = "user_id"/>

<One-to-define class = "com. Neusoft. entity. arrderss"/>

</Set>

</Class>

</Hibernate-mapping>

Here we apply the <Cache Usage = "read-only"/> Configuration. if this policy is used to configure the collection type, Hibernate will only cache the data index, instead of caching entity objects in the set. Run the following code for the above Configuration:

User user = (User) Session. Load (user. Class, "1 ");

Collection addset = user. getaddresses ();

Iterator it = addset. iterator ();

While (it. hasnext ()){

Address = (Address) it. Next ();

System. Out. println (address. getaddress ());

}

System. Out. println ("second query ......");

User user2 = (User) Session. Load (user. Class, "1 ");

Collection it2 = user2.getaddresses ();

While (it2.hasnext ()){

Address address2 = (Address) it2.next ();

System. Out. println (address2.getaddress ());

}

Run this code to get output similar to the following:

Select * from user where id = '1 ';

Select * From address where user_id = '1 ';

Tianjin

Dalian

Second query ......

Select * From address where id = '1 ';

Select * From address where id = '2 ';

Tianjin

Dalian

We can see that when the second query was executed, two queries were performed on the address table. Why? This is because after loading an object for the first time, according to the configuration of the cache policy of the collection type, only the collection data index is cached, and the object objects in the collection are not cached, therefore, when the object is loaded again for the second time, Hibernate finds the data index of the corresponding object, but it cannot find the corresponding object in the cache according to the data index, therefore, Hibernate initiates two select SQL queries based on the data index. This results in a waste of performance. How can we avoid this situation? We must specify a cache policy for the objects in the collection type. Therefore, we need to configure the collection type as follows:

<Hibernate-mapping>

<Class name = "com. Neusoft. entity. User" table = "user">

.....

<Set name = "addresses" table = "address" lazy = "true" inverse = "true">

<Cache Usage = "read-write"/>

<Key column = "user_id"/>

<One-to-define class = "com. Neusoft. entity. arrderss"/>

</Set>

</Class>

</Hibernate-mapping>

At this time, Hibernate will cache the objects in the set type. If you run the above Code again based on this configuration, the following output will be obtained:

Select * from user where id = '1 ';

Select * From address where user_id = '1 ';

Tianjin

Dalian

Second query ......

Tianjin

Dalian

In this case, no SQL statement is used to query data indexes, because the Entity objects stored in the set type can be directly obtained from the cache.

C. Delayed attribute loading:

In hibernate3, a new feature-delayed loading of attributes is introduced, which provides a powerful tool for obtaining high-performance queries. As mentioned above, when reading a big data object, there is a resume field in the user object, which is a Java. SQL. the clob type contains the user's resume information. When we load this object, we have to load this field every time, whether or not we really need it, in addition, reading such big data objects will bring about great performance overhead. In hibernate2, we only break down the user class through the granularity subdivision of the surface performance we mentioned earlier (refer to the discussion in that section ), however, in hibernate3, we can use the property delay loading mechanism to obtain the ability to read data from this field only when we really need to operate on this field, therefore, we must configure our object class as follows:

<Hibernate-mapping>

<Class name = "com. Neusoft. entity. User" table = "user">

......

<Property name = "resume" type = "Java. SQL. clob" column = "resume" lazy = "true"/>

</Class>

</Hibernate-mapping>

You can set true for the lazy attribute of the <property> element to enable delayed loading of the attribute. In hibernate3, to achieve delayed loading of the attribute, the class enhancement tool is used to enhance the class file of the object class. Through the Enhancement Tool, the logic of the callback mechanism of cglib is added to the object class. Here we can see the delayed loading of the attribute, it is implemented through cglib. Cglib is an open-source project of Apache. This class library can manipulate the bytecode of Java classes and dynamically construct class objects that meet the requirements according to the bytecode. Based on the preceding configuration, run the following code:

String SQL = "from user where user. Name = 'zx '";

Query query = session. createquery (SQL); (1)

List list = query. List ();

For (INT I = 0; I <list. Size (); I ++ ){

User user = (User) list. Get (I );

System. Out. println (user. getname ());

System. Out. println (user. getresume (); (2)

}

When executed at (1), an SQL statement similar to the following will be generated:

Select ID, age, name from user where name = 'zx ';

At this time, Hibernate will retrieve all the field data corresponding to the non-delayed loading attribute in the user object. When it is executed at (2), it will generate an SQL statement similar to the following:

Select resume from user where id = '1 ';

In this case, a real read operation is initiated on the resume field data.

 

Spring features:
◆ Convenient decoupling and simplified development through the IOC container provided by spring, we can control the dependency between objects by spring to avoid excessive program coupling caused by hard coding. With Spring, you do not have to write code for underlying requirements such as single-instance mode classes and attribute file parsing, so you can focus more on upper-layer applications.

◆ Support for AOP programming via the AOP function provided by spring to facilitate Aspect-Oriented Programming. Many functions that are not easy to use and implemented by traditional OOP can be easily handled through AOP.

◆ Declarative transactions are supported in spring. We can free up from monotonous Transaction Management Code and manage transactions flexibly in declarative mode to improve development efficiency and quality.

◆ Convenient program testing can be performed in almost all the testing work by using the programming method that is dependent on non-containers. In spring, testing is no longer an expensive operation, but a handy task.

◆ Convenient integration of various excellent frameworks spring does not exclude all kinds of excellent open-source frameworks. On the contrary, spring can reduce the difficulty of using various frameworks. Spring provides various excellent frameworks (such as struts, hibernate, hession, quartz.

◆ Ease of use of Java EE APIs Spring provides a thin encapsulation layer for many difficult Java EE APIs (such as JDBC, javamail, and remote calls) through spring's simple encapsulation, the difficulty of using these Java ee apis is greatly reduced.

◆ Java source code is a classic learning example. Spring's source code design is exquisite, clear in structure, and exclusive. It reflects the Masters' flexible use of Java design patterns and their profound accomplishments in Java technology. The Spring framework source code is undoubtedly a best practice example of Java technology. If you want to quickly improve your Java technology and application development in a short time, learning and studying spring source code will give you unexpected results.