CSLA的商務邏輯

      在使用CSLA之前，一直使用nettiers，也許是因為習慣原因，一直覺得CSLA太不成熟了，至今唯一覺得好用的是他的dataport資料門戶，最討厭的是他對業務對象的操作控制，基本沒有辦法使用。

      他對業務對象的控制是如此的局限性，以至於：

        1。你不能從列表移除一個業務根對象

        2。你只能。。。。

 

        雖然，所有的困難都是可以克服的，但這並不能做為CSLA的“垃圾”商務邏輯的借口

        子物件－》父物件 是其中最令人討厭的商務邏輯設定

        1。由於CSLA對父子物件的設定太過死板，我們不得不將所以的業務對象設定成即有父物件操作，又有子物件操作，以便在不同的情境中使用它們（當然，你可以為每個表建立多個業務對象，但這也不能成為“不垃圾”理由）

        2。業務對象使用不同的操作如果不能算設計中的垃圾之作，那資料門戶只能對父物件進行ROOT就可能得算一個了（地雷啊）

        3。子物件在使用資料門戶的情況下，只能有父物件操作，真正的成為了一個子物件！

        4。還有可能遇到更多的問題

       

        個人覺得，雖然有時候我們可以劃定父物件與子物件，就像男人上男廁所，女人上女廁所一樣，

        但是大部分時候，還是需要業務對象根據我們的劃定來區分，如果我需要他是子物件，他就是一子物件，擁有子物件的操作行為邏輯，如果他是根對象，就應該有跟對象的操作邏輯，大多數時候，我們壓根就不需要區分的那麼清楚，我們只要在需要的時候，把業務對象當作適當的對象擷取就可以了，CSLA做為架構應該實現業務對象的管理，包括父子物件關係，而不是如此簡單的將父子物件區別對待

 

          表達能力有限，文章混亂，只為記錄CSLA中最重要，卻最不貼近實際的問題