Simple Style Web architecture, secondary recovery of JSP + JDBC

For demonstration prototypes, quick delivery is required in the morning or some management functions that are used by a very small number of administrators who do not know how many people have clicked in a year, when you hate PHP and Ror, you will remember the warmth of JSP + JDBC.

Or you can write only the best JSP and SQL, and want him to start working tomorrow .....

So this is done in ss3.Extreme-web style exampleSimplified to the JSP + JDBC of no config file, it is still a similar MVC and is still based on dear spring.

View layer: a JSP

In Web applications, content-based presentation scenarios are the vast majority. We just started with JSP.CodeCall the service bean at the model layer to find the required content.
Do not pull any struts2 action or struts. xml at the end of one page.(SeeWebapp/.../user. jspBytes)

When the content is displayed, you can continue to endure the contempt of others and embed JSP display code directly in the page. You can also put the query results into pagecontext, use jsp2.0 El and jstl taglib for demonstration.

Controller layer: Still a JSP

When a small number of users submit content, they will come to this JSP instead of struts2 action, which calls the service bean at the model layer, and then redirect/forward back to the JSP at the view layer.
If the request is successful, you can use spring's databinder to bind the request parameter to DTO. Otherwise, use N multiple request. getparameter ("foo") for manual combination in the retro mode.(SeeWebapp/.../useraction. jspBytes)

Model layer: A pojo using spring jdbctemplate

Why don't I continue to use JSP and completely change the code without restarting the server? Because spring jdbctemplate/datasource/transcation is reluctant to provide.

If you use @ service of spring 2.5 to register a bean, you do not need to define the bean in applicationcontext. xml.
Then, define the transaction with @ transcational instead of the commit/rollback statement.
Spring simplejdbctemplate is actually quite useful. If you are comfortable with it, you can directly reflect the input parameters and resultset to DTO.
Otherwise, use mapsqlparametersource to bind DTO to the input parameter, and use parameterizedrowmapper to bind the resultset to DTO.(SeeSrc/.../userservice. JavaBytes)

In addition to the above, it also simplifies degradation in other places. For example, the maven function degrades to jar management, and the connection pool directly uses commons-DBCP to define a dependency on the application server...