CSLA架構試用：業務對象分類

　　如標題，這裡說的是CSLA架構中業務對象的分類，剛開始看到時很不理解，為什麼對象還要分類呢，先來以相反的方向描述下平時大家（或者說是我的知識範圍內）所應用的方法。

　　平常操作對象大都是簡單的對象，這裡說簡單是指它只具備對象屬性及對象行為這種單一功能（還有些只是資料填充器），如擷取一個客戶資訊，我們只返回封裝了客戶資訊資料的實體就可以，而要擷取列表，只需要返回List<T>的列表，不管用戶端怎樣使用，對比CSLA的業務對象，它們缺乏了足夠的智能性，也就是各自的職責。或者許說在使用linq2sql或者entity framework，它們有一定的智能性，可以在上下文中跟蹤實體狀態，以及方便的操作對象之間的關係，我也感覺它們與CSLA之間有共性，但對於一個ORM來說或許它們的責任就是以對象的形式封裝資料操作，對於更多的職責來說應用起來還真有點不爽（個人感覺~）。下面就幾類業務對象發表下自己的使用看法。

　　從使用角度來說，對於可編輯對象可以說是使用最廣的業務對象之一，從名稱中就可看得出它的職責是編輯對象資訊，這裡還要分根對象與子物件，對於不同層級的對象它們的操作也是不同，以根對象為例，根對象有責任編寫代碼從持久化裡面擷取對象資訊以及填充屬性值，而向使用者暴露的屬性是經過了封裝過的，封裝了什麼呢？資料驗證，身分識別驗證，錯誤跟蹤，撤銷跟蹤，狀態跟蹤等，客戶去操作對象時在對象背後這些功能都在運轉，這也是根對象的幾項主要功能，架構中向開發人員開放了如AddBusinessRules類似的方法來統一管理如驗證資訊、許可權資訊，對於屬性的的getter,setter來說，在2.0的版本中顯得更直接，而在現在的版本中這些工作都封裝在了基類中。剛才說到子編輯對象，它的職責對於根對象來說大都相同，但它並不對當前對象的資料擷取作操作，而是接收來自上層對象提供的現成資料，所以它沒有DataProtal_Method這種方法，它只是提供資料操作的局部方法而已，在例子中看到甚至這些資料操作方法也是由父物件來操作的。遇到的一個問題就是對象狀態跟蹤的準確性，特別是對於對象初始化時屬性的賦值，它必須在對象內部完成，以前我們喜歡new完一個對象後再為對象預設屬性賦值，因為它們沒有狀態，而在這裡如果後期更新屬性的話對象內部已經對它進行了跟蹤，對於撤銷操作就會有效了，所以這塊需要注意一下...

　　個人比較喜歡的另一個物件類型是唯讀業務對象列表，它是一個清單類型，所以會對應一個唯讀對象子類型作為它的具體資訊，這種列表業務類主要是對資料的擷取以及填充清單項目工作，其他的都是業務方法了，它不會跟蹤對象狀態（也沒必要～），也沒有撤銷等功能，所以效能會比較好，對於唯讀列表綁定感覺它比較適合。這裡對於頻繁使用的並且更新速度慢的資料使用靜態緩衝感覺會比較好。

　　索引值對，這個在平常用的也不少，在這裡好像它與唯讀對象列表差不多，只是簡化了類型和增加了幾個基礎查詢方法。對於簡單的資料還挺方便，好像這種資料更新速度更慢，應用緩衝也是很不錯，同樣它只負責對象載入工作，並沒有可編輯對象那麼複雜，或者它是最簡單的一個業務對象吧，因為對於列表對象可能會有複雜的業務方法。

　　Command對象，這個業務對象應該是最靈活，也是非常重要的一個業務對象，它的結構非常簡單，但可以實現的非常複雜，我感覺這類對象讓架構變的靈活的多。

　　這裡所說的父、子關係，父物件並非就是根對象，這點需要搞清楚。除上面提到的幾種對象外還有其他的變種形式，主要還是根據父子關係的變形，不過也很好理解。

　　自己感覺很好的應用這些業務對象來進行實際開發有一定難度，主要原因不是因為它不好，也不是因為它難，而是從根本上，也就是自己的物件導向水平還有對象設計上還有差距，如果看過DDD就會發現，它們的思路有很多共性，或許它們都是物件導向的具體體現，無論是從對於對象概念還是從對象關係處理，以及從對象職責的角度，所以自己感覺提高思想的水平是學習和應用它們的基礎，這裡是在瞭解業務領域的前提下單純說業務對象的設計，所以與特定領域知識還是息息相關的。

　　腦門突然閃過一道光，在DDD中看到的，自己也感覺很有道理，也適合於CSLA的應用，就是這種架構的應用不是為了提高響應速度，或者說它應該是在響應速度不是最主要目的的情況下應用的架構。

　　這就是今天想到的，下次繼續。
　　[ 附個個人廣告：北京有招人的公司嗎？工齡1.5年，C#，謝謝！QQ：496195435. ]