沒頭沒尾--專案開發筆記 C#企業級模板理解 (轉)

沒頭沒尾--專案開發筆記 C#企業級模板理解 (轉)[@more@]

標題：沒頭沒尾--專案開發筆記

關鍵詞：分散式開發 專案分工

  11月19號：下午，天氣不冷肚子痛

從本質上來說…………，我其實也不清楚C#比有什麼提升。宣傳的材料上或網站上寫的多好多好，從書店買的書看了看也沒看好有什麼特別的地方。都是一大堆的類繼承來繼承去的。管它的，先做出來東東再說。

接著上午的寫吧。我想首先對C#的企業級分散式的模板簡單的說一下。

下面的理解都是我已經忘記是看誰的例子的理解的了，也許是的寵物店例子，也許是別人寫的工程。說的不對的地方兄弟們可以指。

C#的企業級的模板上來就會生成下面七個工程：

1.  DataAccessProjects

資料連線的部分。也就是我們公司討論中號稱的DO層。（Data ）。我認為在這個層寫的原則很簡單，就是除了這裡，其它的地方都不用直接去寫語句。或者直接過程的方法。實現上沒有什麼好說來，來來去去都是些System.Data中間的。

2.  BusinesacadeProjects

OK，這個層就比較的有意思了，我和兄弟部分的同仁一直都在討論這一層與下面那個Rules層有什麼區別。（不要羅）。這裡面還有些曲折。一開始我們用的是VS的英文版，然後我們就天天吵來吵去，比如我一開始就認為這個層是業務規則的封裝，那麼對於基礎的資料操作就應該放在這裡。比如基礎資訊的新增，修改，刪除之類的。只有在刪除時需要從其它的表來判斷刪除操作是不是可以做的時候。才會在Rules層生成一個類，來判斷一下。或者是有什麼事務要進行處理的時候才去用BO。反正一開始都糊塗J，後來有一天，我們搞到了中文版本後，突然發現這個FACADE叫業務外觀層。那麼就是說所有的業務都不能在這裡面做。而是將所有的對DO的操作都封裝在這個裡面。FACADE層真正成為一個（業務外觀）

3.  BusinessRulesProjects

這一層是真正意義上的Business Object，也就是說，三層結構中對應的BO放在這個地方。

4.  SystemsProjects

這一層放置的是物件，比較對處理的統一封裝。（這部分在一開始的時候沒有怎麼用，後來在使用 Service的時候把Application與Session的對應物件的統一處理放在這裡，而不是放在Web Service層。）

5.  Projects

沒說的，web service放置的地方。

6.  WebUIProjects

.NET檔案放置的地方。

7.  WinUIProjects

放置的地方。

這個是自動生成的企業分散式應用的結構。最初我們對這個東東的理解是非常差的，覺得一件這個簡單的事情為什麼要搞的這個複雜。在慢慢的開發過程中漸漸的體會一些好處。我先不說具體的好處。先把我從中體會出來的一些想法與大家分享：

l  為什麼可以這樣寫程式

我想這個原因實在是太簡單了，的技術進步了。哈，硬體的進步讓程式設計師可以不用從頭來寫程式。如果說以前寫100句程式碼可以完成其它人寫1000句程式碼的功能，大家會認為你是高手，可是現在你在跟C#的例子可以發現，一條判斷語句的可能要經過十多級繼承關係的呼叫。大家都是低手？程式設計師要寫的程式碼是比較少了。可以程式設計師寫的程式碼減少不意味真正程式碼執行比以前少了。（為了提交對一張表的修改，我的程式呼叫了近十個類來實現。如果是以前，一定被人罵死。）

l  為什麼要這樣寫程式

這個問題是一個很難回答的問題。但是最初的想法其實這種開發的方式是以降低換來開發的高效率。我不是很清楚網上說的可以用幾個星期的時間來做出一個系統是怎麼回事，不過的確是可以利用這種方式來很好的進行人員的分工，以及對開發過程的改造。這個說起來比較麻煩。回頭再說：）

l  如果這種方式只是工程發展的一個階段，那麼下一個階段會是什麼？

Very Clear.下一個階段一定是大批的程式設計師都失業。要不就改名字。叫什麼架構師，分析師之類的。

l  那我應該怎麼辦？

不知道。好好幹活吧（寫到這裡心情巨差，真不知道以後可以幹什麼。）

 :namespace prefix = o ns = "urn:schemas-microsoft-com::office" />

下一節寫我們專案對企業級模板的一些改造。這些改造我想也是基於對新技術運用的一些思考之後做出的。。希望大家感興趣。