JFinal如何分層？


JFinal 專案通常建議至少 MVC 三層，Controller 是控制層，只做這幾件事：
1：使用 getPara 系列方法獲取請求引數
2：使用得到的 para 做為引數(如果有需要的話)，呼叫業務層
3：將業務層呼叫的結果利用 setAttr 存入 request
4：render
    Model 是業務層，除了封裝業務以外主要注意如下幾點：
1：sql 通常需要寫在業務層，controller 中不要寫 sql
2：可以根據引入單獨的業務層
3：Model 中的業務方通常不要是 static 方法，業務通常是對當前物件而言的，而非全域性。例如有個訂單 model為 Order，那麼判斷該訂單是否已經支付則為  order.isPaid()，而非 Order.isPaid(order)
    View 是檢視層，主要注意如下問題：
1：只讀取並展現資料，絕對不要有業務邏輯，也不要有複雜的邏輯控制
2：當展現邏輯很複雜時，可以建立相應的 Helper 類來輔助生成 String
3：對於通用的view層輔助類，可以建立通用的工具類，全域性共享使用
4：介面佈局一定要使用 layout，極大減少程式碼冗餘提升開發效率，具體可見jfinal_demo專案
   Validator 可以當做是獨立於 MVC 之外的一層，起安全保護作用。訪問資料庫時驗證使用者是否重複屬於業務層的事。
    關於專案模組簡單劃分方式：
1：根據需求設計好資料庫表
2：通常根據資料庫表建好相應的包以及類，例如有 user、blog兩張表，那麼建好 com.xxx.user、com.xxx.blog兩個包，然後在各自的包下建好UserController、User、BlogController、Blog等等類。
3：訪問的路由正好是表名： "/user" 、"/blog"，這正好是 restful 風格。
4：對於不存在表名但需要的功能，可以抽象出資源名，然後做 controller、model


(摘自：http://www.jfinal.com/feedback/296)
jfinal 專案建議分為 MVCS 四層結構：
1：M （Model）層用 jfinal 2.2 生成，model 中不要使用 static Xxx dao 這樣的物件，避免新手誤用，model 中只放一些與欄位狀態相關的方法，例如 User 這個 model 你可以針對 status 欄位，放一個 public boolean isStatusOk() 這樣的方法
2：V （View）層就是展現層，儘可能只去展現資料，避免複雜邏輯
3：C （Controller）是控制層，只負責得到前端引數，轉調業務層，render。避免寫業務邏輯，絕不可寫資料庫查詢之類的程式碼
4：最最核心是 S （service）業務層，基本上來說， 95% 以上的程式碼要寫在這裡，只要是對資料庫的操作程式碼也全部寫在這裡。如果業務層以外需要操作資料庫，那麼也要先在業務層去建立方法，然後再讓業務層以外去轉調這個業務層程式碼，這樣可實現儘可能大的程式碼重用
5：事務控制，我個人習慣於使用 Db.tx(...) 來做，如果要用攔截器，建議使用業務層攔截器，控制層堅持只做我前面 3 中所說的事情
6：只在需要的時候使用介面、抽象類，業務層在絕大部分情況下不需要使用介面，直接是 XxxService.java 就可以了
model 中不要建立 dao 物件以後，將 dao 物件建立在 service 層中這樣來：private static Xxx dao = new Xxx(); 記得是 private，這樣就防止其它業務插手本業務的事情


業務層：
public class XxxService {
public static final XxxService me = new XxxService();
final Xxx dao = new Xxx();


public Ret justDoIt(...) {
if (...)
return Ret.error("msg", "xxxx");
....
return Ret.ok(key, value);
}
}
這樣做以後，外界可以這樣呼叫：XxxService.me.justDoIt(...); dao 物件僅供 XxxService 內部使用，而且由於 me 物件是 static 的，所以內部所有其它的屬性和方法都不要弄成 static 的
此外，如果用到業務層 AOP，將 new XxxService() 改成 Duang.duang(XxxService.class) 即可


package分類

出處:http://blog.csdn.net/u012995856.
config是JFinal的專案配置
controller是控制器
handler可以設定全域性處理器，例如判斷使用者請求中是否直接請求
FreeMarker的模板檔案ftl或者html的字尾，重定向到404
interceptor攔截器，例如後臺admin的每項操作攔截判斷admin是否有許可權或者是否已經登入
model.base用於JFinal的Generator生成器自動生成資料庫對映基礎模型類
model用於繼承基礎模型類的dao操作
routes用於設定單獨路由配置，例如大專案可單獨設計後端路由AdminRoutes、前端路由FrontRoutes
service作為controller與model的層，處理業務邏輯
test用於專案測試
utils用於公共的工具類，例如apache poi的word線上生成列印工具
validate用於後端驗證，比前端JS驗證安全、靠譜


String username = user.getStr("user");//獲取User資料表中欄位為user的值。
String password = user.getStr("password");//獲取User資料表中欄位為password的值。
String sql = User.user.getSql("getUser");//將sql賦值為


public map<string,object> login
Map是以鍵值形式儲存資料，有點類似於陣列。
public是一個訪問修飾符
map<string,object>中string是它的鍵，儲存的型別為String
object是它的值，object為所有資料型別的父類，就是說可以儲存任何型別的資料，呼叫時，可以進行轉型
login是它的方法名
完整的應該是
public map<string（鍵）,object（值）> login(){
//定義一個map，通過put進行賦值，返回
    return map;
}


Description Resource Path  Location Type
Dynamic Web Module 3.0 requires Java 1.6 or newer.


那麼為什麼demo和手冊裡面都有Model.dao這樣的用法呢。
有2個好處。
1 讓做資料訪問時候api呼叫簡潔快速。
2 理論上省記憶體，因為每一次資料訪問的時候使用的是同一個物件。
但是從目前的情況來看起帶來了不好的後果，很多新手有誤用的情況，用靜態的dao物件來承載資料並持久化，這是一個錯誤的用法，是非執行緒安全的。
簡單的說，只有到選擇model做資料訪問的時候才能使用靜態dao物件來呼叫api,其他做實體承載資料的，必須new Model().