為什么有些開發人員從來不用代碼生成器
代碼生成器,我想很多開發人員估計都使用過,起碼也聽說過．為什么有些開發人員從來不用代碼生成器呢，我總結有以下幾種情況：
1.個人習慣，不喜歡用工具，喜歡什么事都親自處理．
2.沒有遇到讓自己特別滿意的代碼生成工具，而自己又不想去改造．
3.有些公司好幾年一直維護那么幾個項目，除非大規模的重構，否則沒有代碼生成器什么事．這類公司注意的業務邏輯，技術深度之類的問題．
企業小項目特點
正好我最近做的項目都是小項目，屬於企業內部的一些系統應用，這種項目有如下特別：
1.規模小，也可以理解為投入的資金不多．
2.人員規模小，一般開發人員加上測試人員不會超過8個.
3.項目周期短，一般不會超過3個月.
4.小規模的項目多．
代碼生成能解決哪些問題
遇到我上述的場景的話，如果有一款適用於企業內部風格的代碼生成器就相當有必要了，它能有效解決如下問題：
1.能夠快速搭建一個項目解決方案，這里指的解決方案是指簡單的創建工程以及分層．
比如，創建什么樣的UI項目，是MVC還是asp.net webform,如何分層，是傳統的三層還是基於領域模型的．
下圖是我生成的項目結構：
2.能夠快速生成一套基於整個公司風格的內部系統UI
這個非常重要，有些公司的系統非常多，但如果每個系統在UI風格上差異太大，不是一件好事,維護難度特別大，而且用戶需要適應不同的系統風格．無論是出於哪方面 考慮，實現一套標准統一的UI對公司是非常有幫助的．
3.能夠快速構建一套對業務數據表進行簡單增刪改查的功能模塊．
只要有數據表，就肯定需要有地方去維護這些數據，我們可以將這些簡單而且枯燥的活讓代碼生成器幫助我們自動完成,誰也不想天天玩那點增刪改查這類hello world．
4.能夠集成大多數通用的解決方案
4.1 記錄數據庫執行情況來分析數據庫查詢性能問題
這個功能在一定程度上能夠幫助我們收集數據庫查詢的情況，能夠比較簡單且直觀的監控數據庫的訪問情況．
4.2 一個比較通用簡單易用的配置功能
它可以簡化程序員對於配置文件的使用，支持基於類對象的訪問方式，當然包含集合型的配置數據讀取．(如何分離web.config改進版本)
4.3 日志功能
可以基於log4net，在此基礎上做進一步的包裝．
4.4 緩存功能，緩存對於具備一定並發性的系統來講都是必不可少的功能模板，成熟的解決方案更加重要．
5.能夠實現統一的倉儲模式
我們可以采用EF 4.3實現存儲功能，然后在些基礎上增加上傳統的倉儲模式．
6.可以構建所有項目的分層結構
比如我們可以在UI層與業務邏輯層之間增加服務層，以此來實現更好的解耦,再比如我們可以在服務層與UI層之間通過Ioc來實現進一步的解耦．
需要注意的地方：
1.代碼生成器最好基於模板形式．
基於模板的工具具備非常強的靈活性，當需要生成其它種類項目時，編寫模板的成本遠低於寫代碼．於是我選擇了T4 text template,微軟的MVC也是采用它來實現，所以我沒有理由不選擇它．
2.代碼生成器不僅僅是生成代碼
如果只是用來生成代碼，我認為還不夠，對我個人來講，我是希望通過它可以將團隊中的各種好的經驗以集成的方式提供給團隊重復使用，優點如下：
2.1 項目成員不用為了同一功能反復找解決方案
2.2 項目成員有一個集中的地方學習一些通用解決方案，是一個重要的學習平台．
在園了里找了一會，發現了一款基於T4的代碼生成器，而且UI是用WPF做的，覺的還不錯就拿下來試試，最終決定在此基礎上做出我自己的代碼生成器．
代碼生成器改進點：
1.原項目不能生成全套的解決方案，只能生成文件．
經過改造后，能夠生成完整的解決方案，用戶直接就能運行．
2.新創建了一套模板．
是采用EF 4.3 Code First模式，UI采用MVC 3,存儲模式為傳統的倉儲模式，同時對於服務器以及UI層引用了Ioc，以實現進一步解耦．
3.修改了部分原項目中個人感覺不太對的地方．
注：原項目文章地址
http://www.cnblogs.com/fangrobert/archive/2011/10/01/2196923.html