標題：沒頭沒尾--項目開發筆記
關鍵詞：分佈式開發 C# 項目分工
11月19號：下午，天氣不冷肚子痛
從本質上來說…………，我其實也不清楚C#比JAVA有什麼提升。宣傳的材料上或網站上寫的多好多好，從書店買的書看了看也沒看好有什麼特別的地方。都是一大堆的類繼承來繼承去的。管它的，先做出來東東再說。
接着上午的寫吧。我想首先對C#的企業級分佈式的模板簡單的說一下。
下面的理解都是我已經忘記是看誰的例子的理解的了，也許是Microsoft的寵物店例子，也許是別人寫的工程。說的不對的地方兄弟們可以指。
C#的企業級的模板上來就會生成下面七個工程：
1. DataAccessProjects
數據連接的部分。也就是我們公司討論中號稱的DO層。（Data Object）。我認爲在這個層寫程序的原則很簡單，就是除了這裏，其它的地方都不用直接去寫SQL語句。或者直接調用存儲過程的方法。實現上沒有什麼好說來，來來去去都是些System.Data中間的對象。
2. BusinessFacadeProjects
OK，這個層就比較的有意思了，我和兄弟部分的同仁一直都在討論這一層與下面那個Rules層有什麼區別。（不要笑話羅）。這裏面還有些曲折。一開始我們用的是VS.net的英文版，然後我們就天天吵來吵去，比如我一開始就認爲這個層是業務規則的封裝，那麼對於基礎的數據操作就應該放在這裏。比如基礎信息的新增，修改，刪除之類的。只有在刪除時需要從其它的表來判斷刪除操作是不是可以做的時候。纔會在Rules層生成一個類，來判斷一下。或者是有什麼事務要進行處理的時候纔去用BO。反正一開始都糊塗J，後來有一天，我們搞到了中文版本後，突然發現這個FACADE叫業務外觀層。那麼就是說所有的業務都不能在這裏面做。而是將所有的對DO的操作都封裝在這個裏面。FACADE層真正成爲一個（業務外觀）
3. BusinessRulesProjects
這一層是真正意義上的Business Object，也就是說，三層結構中對應的BO放在這個地方。
4. SystemFrameworksProjects
這一層放置的是系統對象，比較對安全處理的統一封裝。（這部分在一開始的時候沒有怎麼用，後來在使用Web Service的時候把Application與Session的對應對象的統一處理放在這裏，而不是放在Web Service層。）
5. WebServiceProjects
沒說的，web service文件放置的地方。
6. WebUIProjects
ASP.NET文件放置的地方。
7. WinUIProjects
WinForm放置的地方。
這個是自動生成的企業分佈式應用的結構。最初我們對這個東東的理解是非常差的，覺得一件這個簡單的事情爲什麼要搞的這個複雜。在慢慢的開發過程中漸漸的體會一些好處。我先不說具體的好處。先把我從中體會出來的一些想法與大家分享：
l 爲什麼可以這樣寫程序
我想這個原因實在是太簡單了，硬件的技術進步了。哈，硬件的進步讓程序員可以不用從頭來寫程序。如果說以前寫100句代碼可以完成其它人寫1000句代碼的功能，大家會認爲你是高手，可是現在你在跟C#的例子可以發現，一條判斷語句的執行可能要經過十多級繼承關係的調用。大家都是低手？程序員要寫的代碼是比較少了。可以程序員寫的代碼減少不意味真正代碼執行比以前少了。（爲了提交對數據庫一張表的修改，我的程序調用了近十個類來實現。如果是以前，一定被人罵死。）
l 爲什麼要這樣寫程序
這個問題是一個很難回答的問題。但是最初的想法其實這種開發的方式是以效率降低換來開發的高效率。我不是很清楚網上說的可以用幾個星期的時間來做出一個系統是怎麼回事，不過的確是可以利用這種方式來很好的進行人員的分工，以及對開發過程的改造。這個說起來比較麻煩。回頭再說：）
l 如果這種方式只是軟件工程發展的一個階段，那麼下一個階段會是什麼？
Very Clear.下一個階段一定是大批的程序員都失業。要不就改名字。叫什麼架構師，分析師之類的。
l 那我應該怎麼辦？
不知道。好好幹活吧（寫到這裏心情巨差，真不知道以後可以幹什麼。）
<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
下一節寫我們項目對企業級模板的一些改造。這些改造我想也是基於對新技術運用的一些思考之後做出的。。希望大家感興趣。