基於OOP原則優化

原因：在程序中只要有那個程序功能需要對數據庫進行訪問操作，哪麼必須要有之前的四個步驟：(創建數據庫連接對象-創建數據庫命令對象-針對不同的命令執行結果是否選擇使用另外兩個對象對結果進行處理)

因此：決定使用面向對象的原則對數據庫進行訪問的操作功能進行單獨提取

通用數據訪問類

實現代碼的複用

1. 代碼複用的基本形式：編寫一個通用的方法

2. 代碼複用技術的要求：

   1. 原則：提取不變的，封裝改變的

   2. 技巧：不變的作爲“方法體”，變化的作爲方法的“參數”。

DBHelper/SQLHelper類的封裝

/// <summary>
    /// 數據庫訪問操作類，該對象中提供了對數據庫進行各種操作(增、刪、改、查)的方法
    /// </summary>
    class SQLHelper
    {
        static string con = "Server=.;DataBase=InLettDB;UID=sa;Pwd=123;";
        /// <summary>
        /// 該方法可以對SQL語句執行完成之後返回結果爲受影響行數的SQL語句進行命令執行(增加、刪除、修改數據操作);
        /// </summary>
        /// <param name="sql">要執行的SQL語句</param>
        /// <returns></returns>
        public static int ExecuteNonQuery(string sql)
        {
            SqlConnection sqlCon = new SqlConnection(con);
            SqlCommand cmd = new SqlCommand(sql, sqlCon);
            sqlCon.Open();
            int res = cmd.ExecuteNonQuery();
            sqlCon.Close();
            return res;
        }

        /// <summary>
        ///  該方法可以對SQL語句執行完成之後返回結果中的首行首列數據，適用於SQL語句查詢單一結果值
        /// </summary>
        /// <param name="sql">查詢的SQL語句</param>
        /// <returns></returns>
        public static object ExecuteScalar(string sql)
        {
            SqlConnection sqlCon = new SqlConnection(con);
            SqlCommand cmd = new SqlCommand(sql, sqlCon);
            sqlCon.Open();
            object res = cmd.ExecuteScalar();
            sqlCon.Close();
            return res;
        }
    }

基於對象職責明確原則優化

回顧之前的代碼：數據展示代碼和數據庫訪問代碼混雜編寫在一起

面向對象的基本原則：

1. 單一職責原則(對象職責明確原則)

   要求：一個對象只需要做好一件事情，必須專注，職責過多容易引起變化的原因就越多，程序就不穩定(高內聚，低耦合)

2. 開放封閉原則(核心原則)

   要求：需要變化時儘量少的修改類的設計，而是通過擴展類來完成。即封閉修改，開放擴展

3. 依賴倒置原則(OOP精髓)

   要求：基於接口編程，高層模塊調用接口，底層模塊實現接口，防止底層變化直接影響高層

4. 接口隔離原則

   要求：儘可能多的使用專用的小接口，而不是總接口，避免接口過於複雜

5. 里氏替換原則

   要求：在繼承關係子類可以替換父類，虛擬機可以根據父類變量動態的找到具體的子類對象，從而實現子類

問題分析與解決

前後臺代碼混編的缺點

1. 程序編寫人員必須非常熟悉後臺數據的設計

2. 業務邏輯負責時很難查找錯誤，並且不利於後期的維護

3. 不符合面向對象的設計思想-》違反對象職責明確原則

解決方案

1. 將數據展示代碼和數據訪問代碼進行分離

2. 根據當前需要訪問的後臺實體，創建一個對應的數據訪問類

3. 將該實體操作的方法封裝到對應的數據訪問類型

對象職責明確原則總結

原則

分離“界面代碼”和“數據訪問代碼”

好處

1. 不管是什麼類型的應用程序(Winform/WPF/WebForm/...)當界面法生變化的時候，數據訪問部分一般不需要任何改變

2. 同時前臺設計人員和後臺編寫人員可以很好的分離

注意

當寫程序時，界面中不能出現任何SQL語句，數據訪問後臺代碼中也不應該有其他的業務邏輯代碼

擴展

對象職責明確原則對後續“三層架構”、“工廠模式”、“MVC模式”...打下基礎