不打算寫太長,只寫乙個方面:簡化我們的分層設計，反饋好的話，接著寫...
正常情況下,我們的系統 分為 entity dataaccess business ui 四層,這個我就不羅嗦了.
考慮如下常見情況(舉個最簡單的例子)
比如有兩張表: user, experience. experience 有乙個外來鍵,指向user
考慮沒有ajax的情況，要實現這樣乙個簡單的頁面：某個user的詳細資訊頁面，頁面需要同時列出 user資訊，及這個user的 experience資訊。
正常情況，我們實現此頁面的邏輯為：
資料庫儲存過程級別： 使用 表之間的 join 方式，輸出 user + experience 的復合資訊。
entity layer：將資料庫返回來的資料，分解，分別對映到 某個 user 及 experience 集合。
business layer : 組合兩種型別的 object 返回給頁面
ui layer: 頁面讀取資料...
說明：我寫的這是比較通用的方式，自然有很多其他實現方式，但是，不管怎樣，必然會涉及 同樣一次操作涉及多種物件，導致 伺服器端 要花很多時間處理 這些物件之間的關係。如上的例子，只涉及到 2 張表，1 個級別的關聯，如果實際情況 超過 2 張表，超過 1 個級別呢？...
合理應用 ajax，我們可以完全避免此類情況的出現，任何原子性的操作，只涉及到一種物件
還是對上面的例子：某個user的詳細資訊頁面，頁面需要同時列出 user資訊，及這個user的 experience資訊。
應用ajax我們可以怎麼做呢？
首先直接輸出 user 的詳細資訊，頁面獲取 user 的id 之後，再 ajax 請求 其 experience 資訊。
1. 整個過程 不需要浪費 伺服器資源處理物件之間的關係
2. 每次請求，只涉及乙個型別的物件
3. 無論涉及多少張表，及 多少張表之間的關聯，通過這種方式，均特別容易實現
4. 任何 layer 的設計，只需要正對一種物件 的 （增，刪，改，查...)。
5........
最近寫了三個站點，按時間先後：
1. 自己的站點：[url= 純 ajax **，整個**只有乙個頁面（site map 除外，那不是給人用的，是為seo做的).如果你開啟source code，可以發現，幾乎沒有任何 html **，全部通過js建立 html objects.
2. 公司的專案：[url= ,也是純 ajax 功能站點。 寫了很多控制項 scroll bar , 100行js**+ css 實現的一棵 tree...，四個級別的快取 db-->xml-->cache-->client ......
3. 自己的站點（還沒做完）: [url=本來是打算借這個專案 嘗試 saas 的，推廣了一段時間後發現，國內的使用者 至少5年後才會 認識saas，使用saas不知道要到 猴年馬月，嘗試基本宣告失敗。
站點3，也寫了自己寫了個日曆，嘗試了很多新的東西，另外 [url= 這個頁面，實現了如上的事例 （先顯示房子資訊，然後 ajax 呼叫訂單，反映在右側的日曆上）
謝天謝地，不知不覺也羅嗦了一大堆...
純AJAX的專案的分層
乙個純的ajax專案如何進行分層，這裡沒有了form請求就沒必要乙個請求 結構了吧，也就沒有了針對頁面的action處理了吧，後面聽論壇上人們常說的service也要進行變化了吧？還是我把所有的ajax請求當成乙個action來處理？沒有了資料的轉換，不知道action還有什麼用？那麼我是否應該針對...
ajax的封裝 jq簡化版
最近在複習ajax的知識，練習了下ajax的封裝，此處做下筆記 廢話不多說，直接 發請求 此處的url為請求位址，type為請求方式，success為請求成功的 函式 由於get方法與post方法資料請求的方式不同，需要做下處理 let arr if type.tolowercase get 需要裝...
我們想要怎樣子的生活？
嗯，我們都在努力，都在渴望獲得錢，權利。但是當我們擁有這些後，我們卻發現，我們的生活還是一團糟。有錢了，卻享受不了有錢人應有的生活。工作還是那麼忙，工作還是那麼辛苦，總是渴望賺取更多的錢，但是卻犧牲了家庭，自己的人生。我們為啥要這樣子的生活？在過去兩年，我拼命學習技術，幾乎每日每夜的敲 看相關技術書...