JDBC的業務邏輯流程和模塊開發的原理分析

JDBC的一些簡單的操作

有關jdbc的一些個簡單的操作我是在寫一個接口的過程中學習到的,在這個簡單的服務端接口的編寫過程中我領會了在服務端的分層開發的理念,當然和Android開發的各種架構開發有區別,但是實現原理卻是類似的。

JDBC如何分層各個分層都完成什麼樣的功能

在談到JDBC的過程中首先需要明白的一點那就是對數據庫的操作,其實後臺服務器主要完成的功能就是和數據庫的交互,通過Servlet獲取各種請求命令,然後對後臺的業務(數據庫)進行相關的操作。

接口服務器抽象模型

服務員

服務員的話,主要工作就是直接和客戶進行交流溝通,他完成的工作是整個服務的起點,這一環節談崩了,那麼本次服務流程就不能進行下去。作爲整個服務的出發點,服務員主要的工作內容是從客戶的口中得到服務的類型,然後收取費用,接着下單通知後勤人員買什麼樣的菜,廚師做什麼樣的東西。(這就是我們的Servlet層)

廚師

廚師的話僅僅知道了需要做什麼東西還是遠遠不夠的,他必須要有食材,有佐料,只有具備了這些充分條件,他纔可以開火。雖然不是最爲基礎的條件創造者,但是美味佳餚卻是直接由他來創造的,是與服務類型最直接的交流者,他和服務的關係是創造者與被創造者的關係。這就好比是我們的Dao層是直接與數據庫進行數據交流的關鍵角色。

後勤人員(買東西的人)

後勤人員成爲最爲關鍵的角色稍有不妥,我覺得最爲基礎的角色更加貼切,爲什麼說是基礎呢,因爲他的工作是整個服務進行下去的必要條件,我們去一家餐廳吃飯,然後服務員說沒有菜了,面對這樣的情況我們只能是聳聳肩膀,去光顧其他的餐廳,整個服務也只能到處爲止。類比到項目當中的話,就是我們在操作數據庫之前具有可以初始化操作的一些個工具類。

客戶(服務的消費者)

作爲消費者,我們並不知道整個餐廳的工作體系,我們能接觸到的僅僅是服務員提供給我們的一些個信息(本餐廳都有那些菜,沒有那些菜),而我們要做的事情就是告訴服務員我們要點什麼菜。

三個不同角色完成的具體操作

Servlet層

Servlet層主要完成的工作就是獲取請求的類型(消費者點的是什麼菜),他的兩端面臨的一個是消費者一個則是餐廳的工作人員,所以他完成的操作動作是獲取請求方式,然後將請求方式告訴後臺的業務層。下邊是一段有關Servlet的代碼:

@WebServlet("/examInfo")
public class GetQuestions extends HttpServlet{

    private static final long serialVersionUID=1L;
    private IQuestionBiz biz=new QuestionBizImpl();

    @Override
    protected void doGet(HttpServletRequest request,HttpServletResponse response) throws Servletexception,IOException{
        response.setCharacterEncoding("utf-8");
        response.setContentType("text/html,charset=utf-8");
        String testType=request.getParameter("testType");
        String json=biz.getQuestions(testType);
        response.getWriter().println(json);
    }
    protected void doPost(HttpServletRequest request,HttpServletResponse response) throws ServletException,IOException{
        doGet(request,response);
    }

}

分析以上代碼就很容易發現我們首先通過request.getParameter(“testType”)拿到了客戶端的請求類型,然後將得到的請求類型通過biz.getQuestions(testType)方法傳遞給業務層,當然Servlet層也是通過這個方法得到後臺的數據的,最後通過response.getWriter().println(json)方法將從業務層拿到的數據返回給客戶端。

Dao層

Dao層就像我們之前說的一樣主要完成的是直接和數據庫進行交互,一方面要完成對數據庫的操作另外一方面要將從數據庫得到的數據進行實體類的封裝,並通過接口的形式將數據返回給其他層。

public class QuestionDaoImpl implements IQuestion{
    @Override
    public List<Result> getAll(){
    /**
     *JDBC三大基本操作類
     **/
        Connection conn=DBUtil.getConn();
        PreparedStatement ps=null;
        ResultSet rs=null;
        List<Result> list=new ArrayList<Result>();
        try{
            ps=conn.prepareStatement("select * from t_question");
            rs=ps.executeQuery();
            while(rs.next()){
                int id=rs.getInt("id");
                String question=rs.getString("question");
                String answer=rs.getString("answer");
                Result result=new Result(id,question,answer);
                list.add(result);
            }
        }catch(SQLException e){
            e.printStackTrace();
        }finally{
            DBUtil.closeAll(conn,ps,rs);
        }
        return list;

    }
}

正像之前所說的一樣Dao層完成的就是數據庫數據的封裝,封裝完成之後通過接口的形式將封裝好的數據提供給其他層。

Util層

Util層主要完成的就是操作數據庫之前的一些個初始化編碼,我們知道數據庫操作無非是這樣的一個步驟:1.DriverManager的初始化我們一般通過Class.forName(“com.mysql.jdbc.Driver”)來完成。然後我們要獲取一個Connection對象這個對象的獲取方式我們是通過調用這樣的方法DriverManager.getConnnection(jdbcUrl)的方式獲取到一個連接,這樣就完成了對Mysql數據庫的連接。在連接的過程中我們往往不是將jdbcDriver或者jdbcUrl直接寫入到代碼中,往往是將相關的配置放在properties配置文件中,通過另外定義一個工具類獲取其中的配置參數,以下爲詳細的代碼:


public class DBUtil{

    public static Connection getConn(){
        Connection conn=null;
        try{
            class.forName(PropertiesUtil.getValue("jdbcDriver","jdbc.properties"));
            conn=DriverManager.getConnection(PropertiesUtil.getValue()"jdbcUrl","jdbc.properties");
        }catch(ClassNotFoundException e){
            e.printStackTrace();
        }catch(SQLException e){
            e.printStackTrace();
        }
        return conn;
    }
    public static void closeAll(Connection conn,PreparedStatement ps,ResultSet rs){
        try{
            if(conn!=null){
                conn.close();
            }

        }catch(SQLException e){
            e.printStackTrace();
        }
        try{
            if(ps!=null){
                ps.close();
            }

        }catch(SQLException e){
            e.printStackTrace();
        }
        try{
            if(rs!=null){
                rs.close();
            }

        }catch(SQLException e){
            e.printStackTrace();
        }
    }
}

接下來是Properties的相關代碼:


public class PropertiesUtil{
    public static String getValue(String key ,String proName){
        String value=null;
        Properties  p=new Properties();
        String path=PropertiesUtil.class.getResource("/").getPath();
        try{
            p.load(new FileInputStream(new File(path,proName)));
            value=p.getProperty(key);  

        }catch(FileNotFoundException e){
            e.printStackTrace();
        }catch(IOException e){
            e.printStackTrace();
        }
        return value;
    }
}

總結:

通過對整個模塊的分析我們得到了這樣的幾個關鍵的結論:1. 業務分層的本質就是服務操作的封裝(消費者不知道公司的內部工作詳情)。2. 接口中的方法如果沒有返回類型的話想要通過回調實現數據的返回可以通過以接口爲方法參數的方式來實現。3.面向接口編程的本質以及JDBC的基本編碼流程。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章