原來不知道自己想要什么，一般習慣于三層，而且還是bll簡單化的三層，現在是越來越清晰的明白自己想要什么了。

簡單化的三層存在的問題：

1.表驅動的，N個表，就有N*3個類。

2.業務全部被放到了界面后面隱藏的類里面去了。換界面不容易。

3.業務復雜的話，修改起來比較崩潰。比如說一個業務有5個表參加了，那么里面的業務代碼長，復雜，表的關系也是復雜。繞來繞去頭暈了。

修改起來也是小心異常。

原來打算使用DDD驅動，但是這個東西，首先要有業務專家，分析起來頭大，水平不夠就算了。所以就選用了csla.net。

最后參加了幾個復雜一些的項目。我發現，我只需要這樣三個東西來做業務:

1.業務類，應該是UI對應的類，而不是簡單的D2O,O2D的傳輸類。它的屬性要更符合業務字段(其實是用戶接口或者叫UI)的類。比如說，文章里面有一個叫類型的屬性，

兩種方式，傳輸類，只有類型的編號，傳輸類，引用了類型。我想用第三種，將類型的名稱也放到傳輸類里面，

從業務上面來看，文章本來就有一叫類型的屬性，用戶接口里面用的就是名稱，只有程序員才知道用編號。

在有一些簡單系統里面可能就只有一個叫類型的屬性，它只有一個字段。

2.上下文，應該叫表達式吧。以往的編碼，剛入行時，人家告訴我們說，根據名稱獲取某條信息，你要寫...ByName,根據ID獲取某條信息，你要寫...ByID,

最后你要重載一個，好多參數的方法，或者是參數類的方法。所以一個BLL里面一大堆方法下來。不如一個方法。用表達式來做參數。更加清晰明了。而且一般的

表達式，你不用特殊的解析，前面UI對應的類做好了，后面的查詢一般都在UI里面有了。不需要做特別的處理。有一些特別的規則，比如說，狀態為true，才能用，

這個可以默到表達式里面。還有環境上下文，當前用戶相關的環境上下文【數據權限、業務權限】等。

3.UI輔助類。幫助業務邏輯與UI交互，在做很多業務的時候，會有，你是否。。。。。，是，否的詢問，為了這個交互，只好把業務放到了UI的后臺類里面，這是正確的，

但是不好看。而且寫程序不能像寫文章那樣，一氣呵成，中間，會被這個交互打斷了，【一般是從winform到webform或者是mvc的時候】。

UI的邏輯本身比較復雜。但是在業務中使用的，大體上面，只有樹，樹列表，列表，工具欄，下拉菜單，連動選擇控件，輸入限制控件，而且如果是做業務系統，UI一般，

風格比較固定，所以統一是可行的。

此時UI可以由一個人做，業務由另一個人做，統一的接口是UI輔助類。業務通過特性指定UI的類型。UI的外觀，由另一個人處理，圓的按鈕，方的按鈕，怎么放。寫到模板里。

博客園真的是讓人成長，這些思維也不是亂想的，oea的UI就是這樣的。csla在數據門戶上體現一種，數據操作也是業務的一部分，某人寫的POCO真的那么重要嗎，我看到了上下文，

表達式的好處，接合csla，這個是真的可以特別的靈活。從csla上，我看到了UI和業務類的統一。以往我看oea的方式，我覺得復雜，不靈活，難用，現在，我還不會用，

但是，我覺得是用這種方式在做業務的時候真的變的簡單了，以往我會被打斷，這個查詢沒有寫，趕快去BLL，DAL里面加。這個放在這不行，因為要和用戶交互，沒有引用到UI的框架，

然后copy,past。一個UI后臺類，寫到上萬行，很正常。無所保證其完全正確，寫單元測試，寫不了，很正常。

雖然不是唯一的開發方式，但對我來說，是比較合適我的開發的。

題外話，如果不是csla和oea開源還有很多人分享他們的思路和源碼，那么我現在應該積極的去做管理了，這種工作多好，

跟領導吹吹牛，侃侃大山，壓力來了，分給下面的人，哪有什么壓力。有功自己領，拿點湯給別人，有錯，下面人的問題。

轉載于:https://www.cnblogs.com/forhell/archive/2013/05/25/3098521.html

總結

以上是生活随笔為你收集整理的思维的新发展的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。