csla.net中分享商務邏輯

 

 閑暇時間看了下前些天買的關於CSLA架構的書，摘抄了一些。

  ...剩下的方案是把商務邏輯集中在部署在客戶機（或web伺服器）的商務邏輯層，這樣UI層就可以訪問商務邏輯，部署在應用伺服器商務邏輯層中，這樣商務邏輯就可以有效地與資料訪問層互動。這樣的做法能同時獲得這兩種方案的好處：豐富互動性的使用者梭和訪問資料庫（或其他資料來源）時高效高效能的幕後處理。

  在沒有應用伺服器的簡單情況下，商務邏輯只被部署一次：在客戶機或者web伺服器上。

  在理想化的情況下，商務邏輯在與使用者互動的時候會與UI代碼運行在同一台電腦上，而在訪問資料庫的時候會與資料存取碼運行在同一台電腦上（像前面講座過的，所有的這些代碼運行在哪台電腦上取決於系統物理的架構）。商務邏輯必須提供一個友好的介面方便UI開發人員使用來調用資料驗證和處理的邏輯，而且還必須能高效地使用資料訪問層來讀取和寫入資料。

  用來解決這個看起來很棘手的需求的工具就是封裝了應用程式的資料和相關商務邏輯的移動業務對象。一個合理構建的業務對象可以在網路中從一台電腦移動到另一台電腦，幾乎不需要你做什麼。NET架構本身會處理底層的細節，而你可以把精力集中在商務邏輯和資料上。

  如果很好地設計並實現了移動業務對象，你就可以讓。NET架構在網路中按值來傳遞你的對象，也就是自動把對象從一台電腦複製到另一台電腦。這需要額外很少的一點兒代碼。你可以把你的商務邏輯和業務資料移動到UI層所在的電腦，然後在需要資料訪問的時候將他們轉移到資料訪問層所在的電腦上。

  同時，如果你把UI層和資料訪問層進行在同一台電腦上，那麼。NET架構就不會移動或複製你的業務對象，這兩層都直接使用它們，這樣就不會造成效能降低或額外的開銷，你也不必為此作任何事情，。NET會自動檢測到該對象無須被複製或移動，因此也不會作任何的動作。

  商務邏輯層會因為而變得輕便靈活或移動，而且能適應所在的應用程式部署的實體環境。因此，你可以用一個基本程式碼程式庫支援多種物理N層架構，由此你的業務對象無肱飲食額外的代碼來支援多種可能的部署情況，你需要實現支援對象在電腦間移動的那部分少量代碼會被封裝在架構中，這使得業務開發人員可以把精力全部集中在商務邏輯的開發上面。

 

  以上是自己感覺很有意義的幾段話，在此分享給大家，此架構確實很牛*。

  因為自己能力有限，所以開發酷易化妝品商城（www.koyee.net）站花了不少的精力和時間，也學習了不少，有興趣的朋友可以提出寶貴意見，以後一段時間會把過程中遇到的問題和學到的開發技巧寫下來和大家一塊分享，同時也遺留了許多的問題還要請教大家，也希望有學習或正在使用csla.net架構的朋友多幫忙一下，可以加QQ：496195435