So far, we have not been exposed to the substantive issues of user registration, that is, adding users to the database. Let's deal with this demand now.
First, you need to determine the technology used for database access. Here you can choose hibernate, JPA, or JDBC. I believe that most applications use hibernate as the database access technology. Others may choose JPA, but here we choose JDBC. The reason is relatively simple. The underlying things seem to be complicated, but once mastered, it is relatively easier to master because of its low content. While this O-R ing model adds a lot of abstract concepts and details, we usually only look at the tip of these architecture iceberg, and if you want to grasp the thing below the iceberg, it is several orders of magnitude more difficult than to directly master JDBC.
In addition, because of our test-driven development architecture, we want to switch to other architectures, And we can refactor the existing code. With the help of test cases, we can safely modify the code.
Well, we should first use the DAO mode to define the database access interface class userdao. The Code is as follows:
public interface UserDao {public long registerUser(Map<String, Object> userInfo);}
Generally, we use the MySQL database, so we define the DAO implementation class usermysqldao. The Code is as follows:
public class UserMysqlDao implements UserDao {@Overridepublic long registerUser(Map<String, Object> userInfo) {// TODO Auto-generated method stubreturn 0;}
Of course, we do not want users to determine the database to be used, and then instantiate the corresponding implementation class. Therefore, we need to adopt the factory mode and introduce the daofactory class. The Code is as follows:
public class DaoFactory {public static UserDao getUserDao() {UserDao dao = null;switch (dbms) {case "mysql":dao = new UserMysqlDao();break;}return dao;}public static String getDbms() {return dbms;}public static void setDbms(String dbms) {DaoFactory.dbms = dbms;}private static String dbms = "mysql";}
The code above shows that the caller only needs to call daofactory. getuserdao () to obtain the implementation class.
The following is the database connection problem. We hope to use the database connection pool when running on JBoss and other application servers, and use drivermanager in unit testing, therefore, you need to define a datasource encapsulation class jdbcds to handle the above situation. The Code is as follows:
public class JdbcDs {public static Connection getConnection() throws SQLException {Connection conn = null;if (iDebug <= 0) {conn = appDs.getConnection();} else {try {Class.forName("com.mysql.jdbc.Driver").newInstance();} catch (InstantiationException e) {// TODO Auto-generated catch blocke.printStackTrace();} catch (IllegalAccessException e) {// TODO Auto-generated catch blocke.printStackTrace();} catch (ClassNotFoundException e) {// TODO Auto-generated catch blocke.printStackTrace();}Properties connectionProps = new Properties(); connectionProps.put("user", "root"); connectionProps.put("password", "yantao"); conn = DriverManager.getConnection( "jdbc:" + "mysql" + "://" + "localhost" + ":" + 3306 + "/XrcjDb", connectionProps);}return conn;}public static int iDebug = 1;public final static String APP_DS = "java:jboss/datasources/XcgDS";private static DataSource appDs = null; static{if (null == appDs) {Properties env = new Properties();try {InitialContext ictx = new InitialContext(env);appDs = (DataSource)ictx.lookup(APP_DS);} catch (NamingException e1) {// TODO Auto-generated catch blocke1.printStackTrace();}}}}
For unit tests, you only need to set idebug to 1. Otherwise, the database connection pool is used.
After all the preparations, we can officially develop the database functions.