概述
一般的業務系統都需要記錄用戶的操作行為和監控用戶對數據的改動，以便事后監察或分析問題原因。jeecg 框架已默認提供了“系統日志”和“數據日志”這兩個模塊，下面讓我們來看一下它是怎么實現的吧。
系統日志
首先，讓我們看一下最終的展示效果：
從截圖可以看出，系統日志記錄了用戶的行為類型、日志內容、IP、用戶信息、瀏覽器、操作時間等數據。然后從代碼分析得知，這些數據都保存在 t_s_log 這張表中。接下來，讓我們跟著代碼看看是怎么獲取數據并插入到數據庫的。
以用戶退出的日志舉例，在 LoginController.logout( ) 方法里調用了 SystemService.addLog( ) 方法，傳入了“日志內容”、“日志類型”、“日志級別”這三個數據，不過開發人員把“日志類型”和“日志級別”這兩個參數搞反了（v3.7.2版本），由于在數據庫都是用的數字保存，在界面上轉義回文字時也能有對應的值，也不影響查看，只是大家留意有這個問題即可。而在 addLog( ) 方法里，代碼構造了一個 TSLog 對象，然后把各字段的值保存進去，用戶的IP、瀏覽器信息可從 Request 對象獲取，用戶信息則從 session 中獲取。最后，調用對應的 Dao 對象方法，把實體對象保存到數據庫里。
從代碼分析可以看出，jeecg 框架對行為日志的記錄是直接嵌入到業務代碼里的，要記錄哪些類型的日志，需要在調用的對應業務方法里增加 addLog( ) 方法的調用，并定義好日志類型的 code 和日志內容格式。這種實現方式可能開發人員在寫代碼時思路會比較順暢，但缺點是不靈活且重復代碼較多。
數據日志
讓我們再看一下數據日志的實現。同樣，先來一張截圖看下展示效果：
數據日志記錄下了數據所在的表名、數據id、數據版本號、數據內容、創建人等內容，保存在 t_s_data_log 這張表里。其中，數據內容是以 json 格式序列化的字符串。當選擇兩條同一張表的數據時，還提供了“數據比較”功能，如果是同一個數據id的不同版本數據，就可以看出這兩個版本的數據差異了。
下面來分析一下代碼實現，在 SystemService 類提供了 public void addDataLog(String tableName, String dataId, String dataContent);
方法，傳入表名、數據id和 json 格式的數據內容即可插入數據。再看下 SystemServiceImpl 實現類里該方法的實現邏輯，先從 t_s_data_log 表根據表名和數據id查詢出當前最大的版本id，然后把版本id加1，構造出一個新的數據實體，然后持久化到數據庫里，便完成了。經過代碼搜索，框架里已有模塊的代碼里并沒有調用 addDataLog( ) 方法的地方，但應用的方式應該跟行為日志的調用方式一致，在對數據做增刪改時，都可以調用方法插入一條數據變更日志。
一些思考
關于行為日志和數據日志的記錄，我在以前的公司使用的框架也有類似的封裝，但相較于 jeecg 框架的實現，會更靈活些。我們是采用 AOP 的方式對業務方法做編織，實現業務與日志的解耦，然后通過配置文件配置需要采集日志的業務方法，并配置用來標識的 code 及一些描述信息。而對數據日志的記錄，則是在jdbc層對要執行的 sql 做攔截，類似 druid 連接池對 sql 的解析，得到本次操作要修改的數據，然后插入到數據庫。
以上方式對日志的采集，都是為了在一套系統內完成所有的事情，難免會對業務系統的正常運行造成性能影響或是邏輯上的侵入。而現在互聯網公司的做法，一般對行為日志的采集交由前端統一上報到日志系統，而對數據日志的采集則是根據交易流水號，打印詳細的交易日志，然后用日志分析系統采集日志文件數據，做到業務系統與日志系統相隔離。
沒有最好的方案，只有最適合的方案。開發時應根據實際需求的規模、工期、要求等等因素，選取最適合項目的技術方案。
