本期特邀.NET與項目管理專家、暢銷書作者李天平老師，針對.NET開發與項目管理的問題給予解答，歡迎網友積極提問，與專家一起討論!
查看本期門診精彩實錄：http://doctor.51cto.com/develop-277.html
專家博客：http://litianping.blog.51cto.com/
精選本期網友提問與專家解答，以供網友學習參考。
Q: 很高興能得到專家的親自指點的機會，我現在還只是一個大二的學生，學的也是.NET軟件開發，問的問題可能有些幼稚，希望見諒。
我的問題有兩個，第一個是.NET開發的接口爲什麼那麼少？不像java，很多東西都可以直接用人家發出來的接口。
第二個：asp.net做的網站經常被***光顧，拿到webshell而提取服務器，我們在做項目中應該從什麼方面來注意這個問題？
A: 第一個問題，我感覺還是接觸知識面的問題。第二個問題，主要應該做好windows的系統安全防範，補丁及時更新，安全相關防火牆軟件，另外確保自己寫的代碼沒有注入漏洞，做好頁面權限控制。很多時候安全問題並非ASP.NET的錯，更多時候是由於技術人員的安全意識問題。
Q: 很高興能得到專家的親自指點的機會，在這裏表示萬分感謝！
.Net 標準控件的效率通常比較慢，在一個項目中會自定義控件還是使用第三方控件？
在提高效能方面，主要是在哪些方面做改善？
A: 在控件使用方面，一般需要考慮項目的性質，如果是網站性質的，性能要求比較高，建議少用控件，控件會產生很多頁面負載，導致頁面加載比較慢。如果是管理系統類內部項目，由於併發不大，通過控件可以大大提高開發效率。具體提高性能方法方面，建議看一下《項目中的.NET》的第15章大型網站的性能優化與安全有詳細的介紹。
Q: 很高興能得到專家的親自指點的機會，熟知.NET的開發、部署、實施都會存在各種漏洞和不安全因數，不知您是如何實現安全保障的？還有.NET與其它開源軟件相比其開發、維護成本您認爲如何？
A: 系統的安全往往來自於三個方面，開發的軟件本身有漏洞；操作系統；硬件網絡安全；人們印象中的.NET安全問題其實大多由於.NET軟件必須部署在windows平臺所致，過去的windows系統的一些安全問題讓人有一種誤解。軟件方面更多考慮注入***，安全驗證等方面；系統方面做好各種補丁和防火牆安全軟件；多加監控沒有人們想象的那麼差。其實有很多大型系統是基於.NET開發的。很多時候安全問題並非.NET的罪過。
Q: 李老師，您好，很高興有機會能跟您請教一下.net相關技術。我想提問3個問題，請老師能夠給予解答指導，謝謝。
1、很多人認爲.net跟java一樣都是高級語言，封閉了很多的實現細節。在強大的ide工具vs的幫助之下，運用先進的可視化控件技術來實現編程，通過拖拖拽拽就能快速搭建一個系統。但是vs提供的這些控件感覺都是個半成品，很難達到實際生產的要求，在這種背景之下，很多的第三方控件出現了，比如：devexpress、aspnetpager等等。爲什麼微軟不開發一套官方的統一的強大的能開發商業系統的控件呢？就像jquery的jquery ui一樣。
2、早在09年的時候，我就在一項目中使用了您的動軟代碼生成器，當時覺得很好很不錯，也就在那時知道了你的名字。這麼多年下來，您認爲動軟代碼生成器能成功的運作起來，其原因是什麼呢？後來我在項目中，也用到了很多其它的代碼生成器，甚至是自己開發的一套代碼生成器。作爲一個成熟的成功的產品，動軟代碼生成器成功的原因是什麼呢？動軟代碼生成器的開發模式是怎樣的，是怎麼一步一步發展起來的。
3、我們都知道最新的vs2012開發工具和win8、windows phone 8 sdk開發包都已經提供下載了，您認爲在這個全新領域，個人開發者應該如何識別機會、抓住機遇？您認爲未來.net發展的趨勢是什麼？
A: 1. 至於微軟爲什麼沒有開發這樣的控件類庫，我不能確切的知道他的內部戰略。但我的個人感覺微軟作爲這樣的一家龐大公司不可能把產業鏈上所有的事情都做了，也沒有那麼大的精力，總有一些創新和改變來自於草根和細分的領域，創造很多各種各樣的機會。大樹底下會長草。
2. 動軟代碼生成器的成功，個人感覺來源於底層現實的需求，不是玩一個概念，而是實際帶來的價值和便利，同時堅持把產品做好，才能讓更多的用戶進行口口相傳。“用智慧改變世界，用創造改變生活，其實，工作也很快樂！” 是動軟最原始的理想和文化，先談價值再談價格是動軟一直奉行的原則。
3.全新的領域充滿機會，也充滿挑戰，機會和機遇都需要建立在一定的積累的基礎上，早一步是先烈，晚一步是紅海，所以，堅持合適的時間做合適的事情是個好的原則。
Q: 李老師:
您好!
我單獨參加過軟件工程師培訓，學過.NET，也學過JAVA,但是一直未入開發這一行業。
我需要如何才能進入角色?
我現目前在做虛擬化，統一溝通項目規劃、實施方面的工作。
因爲學習和項目還是有差距，你認爲如何進入這人開發人員角色。
有什麼好推薦?
A: 如果真的想要進入這一行，需要有意識的從相關小事開始做起，增加這方面的鍛鍊和實踐經驗。當有了一定的積累，可以從事這個工作的時候，哪怕最基層的工作，就可以開始進入這個領域。隨着經驗和能力的提升，慢慢就會真正成爲這個角色。目標決定過程，什麼樣的目標決定了這個過程中走什麼樣的路。
Q: 目前net開發，對應asp.net mvc越來越重視了，但是mvc經過幾個版本的更新，使用起來還是沒有傳統的asp.net控件拖拉式的方便快捷，尤其時在對原來項目升級時，遇到問題；對於項目開發，我們應該使用更爲成熟的東西，還是不斷去新呢，有時很是難以取捨，對於傳統的asp.net開發遇到穩定在百度中基本解決，但是用mvc4開發時，很多問題讓我焦頭爛額；有時上邊壓着用新技術其實感覺就是在投標中說明一個亮點，客戶對於新的東西其實沒有什麼真正的概念
A: 你的問題可能不簡單是個技術問題，我從幾個方面分析一下，
1. 對於技術而言，只有最適合的技術，沒有最好的技術。是否採用新技術，需要根據項目的情況和個人的實際情況分析，採用哪種技術。項目的目標是實現功能，不是爲了技術而技術。
2. 新技術往往帶有一些不確定性，不成熟的風險，及自身不熟悉，造成開發效率低，可能帶來的項目開發延期和更多的開發成本。
3. 如果是爲了投標而以新技術作爲亮點，這個問題就不是技術問題了，從商務的角度講，也許可以帶來項目或者帶來更多的利潤，來支撐你們提供更多的開發成本。否則，如果週期壓得很緊，風險可能會比較大，可能會導致項目的失敗和延期。
4. 另外的角度分析webform和MVC有着各自的優勢，根據不同的項目和需求選擇合適的技術，webform有着各種拖拉控件雖然方便快捷，但是這是以性能作爲代價換來的。如果是企業內部管理系統類的項目，其實目前你們用webform比較合適，併發沒有那麼大，性能損失完全可以承受，又你們比較熟，開發效率高，節省成本。如果是你們的項目規劃確實用到MVC的某些特性對你們的項目更合適，那麼你們需要分析一下，預留一定的項目緩衝時間，學一下了。
關鍵的問題，需要你們自己做好項目分析，內部充分溝通，再做技術選型。
Q: 老師好，從個人的一年多的開發經歷來講，我覺得.net平臺的優點在於入門比較容易，開發週期短，基於可視化編程，我不會特別留意前臺界面的設計，省去了很多麻煩，但是帶來了更多麻煩，很多底層的東西不清楚，導致了出現問題時會一頭霧水，當然，最重要的是，同一個功能，比如用戶登錄驗證，我可以再前臺用Javascript去完成它，但是更好的辦法是利用面嚮對象語言的特徵，自己完成Class的初始化和Interface的實現，大家都明白這樣子降低耦合，有利於程序後期的維護和擴展，問題是在實際的開發過程中，如何選擇？怎樣更清楚的認識和了解底層的東西？linux的樂趣在於很多基礎命令的驚豔，如果在我們自己的開發中，能夠容易的在底層命令和封裝好的Interface之間隨意切換，豈不是美事一樁？（相信很多.net的同行不願意被別人理解爲組裝工程師。）
A: 1..NET 的初衷就是省去一些內部的技術細節，而專注於自己應用業務的開發，畢竟，做開發不是爲了技術而技術，是爲了創造價值，是爲了實現項目功能。
2. 其次，大部分只有初級開發的時候，纔會只通過可視化編程或者拖拽控件，現成類庫實現一些簡單的應用，一個高級的開發人員或架構師，同樣會去研究深層次的內容，面向對象，設計模式，架構等等。大型的項目很多都是需要自己寫的，這樣才能更好的擴展和可維護。這和淺層次的簡單開發並不是一回事，.NET開發也有底層，只是有的人把日常從事的工作讓自己誤認爲這是.NET的全部。
Q: 李老師，你好。經過一年多的.Net開發，我從一個完全不懂開發的人成爲了剛剛入門的小菜，也逐漸產生了疑問。
一開始的開發，我也是拖控件，在後臺寫相關聯的事件，開發起來效率真的很高，可是隨着數據量和業務邏輯逐漸增多，網站的運行效率也越來越慢，最近我在嘗試脫離這些服務器控件，使用一些js開發框架來完成前臺的展示，將C#作爲處理服務器數據的載體。
我想問下，Asp.Net中，這樣做的團隊或者企業是否很多呢？我應該看看哪些相關的知識呢？
A: 小項目往往通過控件可以短平快實現，可提高開發效率，因爲對系統性能和複雜度要求不高。真正的大項目往往要考慮性能，安全性，併發負載，擴展，靈活維護等等因素，將很少使用控件拖拽實現。同時會自己封裝一些組件或者模塊化實現相關功能。這好比過去的傻瓜相機可以滿足基本的照相需求，但是專業攝影，還是需要單反或者更專業的相機一樣的道理。還是需要學習更深層地專業知識才能照出更專業的照片。