我喜歡struts，喜歡ibatis，喜歡spring，但我卻喜歡.net，這實在是件很矛盾的事情。.net很好用，但在做項目的過程，總覺得缺少了點什麼，對了，是框架。在java的世界裡，有著許多成熟優秀的框架，但.net的框架，可選擇的實在很少。在盼星星盼月亮的漫長過程裡，終於盼到了Asp.net MVC，恕我不才，看來看去，都覺得這Asp.net MVC用起來實在是麻煩。我還是喜歡使用struts，盡管我很煩惱那些配置文件，但配置文件確實給我們帶來了很多的好處。能輕松的擴展，輕易的修改。不過tomcat實在很垃圾，修改了配置文件居然還要重啟。我喜歡.net，喜歡c#，喜歡Visual Studio，我覺得c#使用起來很自然，很舒服。然而，我害怕面對一張復雜的表單，想要獲取幾十個，上百個數據項實在是種痛苦。我經常的想，要是.net也有個struts的框架該多好啊，既然沒有，那麼，就讓我來設計一個吧。
當然，struts的設計並不是為了僅僅解決獲取表單數據麻煩的事情，要是僅僅如此，那就實在是太大題小作了，封裝表單數據只是它的功能的開始，有了數據還需要對它們進行驗證。有些人可能覺得，數據驗證我都在前台進行了，後台就不需要對數據再進行驗證，我只想說，這實在是件很危險的事情。我不打算討論前台數據驗證可不可靠，我個人覺得，它是不可靠的，即使它可靠，但是多一層的驗證不是更確保系統的安全嗎？驗證完數據之後就是執行業務邏輯了，然後就是頁面的跳轉或者返回請求的頁面。Struts讓這個流程自動地執行了，我們所要做的，只是往Validate和Execute這兩個方法中添加邏輯代碼。根據ISO的管理理念，員工做的事情越單一，熟練度也就越高，出錯的幾率就越小。struts的設計，是完全符合軟件工程的設計思想的。
配置文件是struts核心的一部分，許多人都不喜歡使用配置文件，我也是其中一個。記得剛開始接觸struts的時候，對它的配置文件實在是很煩，但慢慢地，了解了配置文件的作用之後，就喜歡上使用配置文件了。配置文件在項目中的作用是毋庸置疑的，在大型的項目中尤其重要。需求是不斷地改變的，但我們的程序可不能老跟著需求變，即使老板吃得消，員工也吃不消啊。改變一個頁面的業務邏輯，只需要在配置文件中修改一下action的配置就可以了，其它的代碼都不需要改變。說到配置文件，它還有一個很重要的作用，那就是“控制反轉”或者“依賴注入”，其實我也搞不清這兩個詞語之間是什麼關系。不過，也沒必要在這些文字間咬文嚼字，就用IOC來代替它們好了。在開發過程中，經驗會遇到一個類裡面包含另一個類的實例，如：
class A
{
………..
}
class B
{
A a = new A();
}
那麼，在上面的代碼中，B將依賴於A，也就是說，沒有A，B就無法正常的執行。這樣，B和A就產生了耦合。說得再明白一點，如果B的業務邏輯需要改變了，不想使用A，而是使用C，那麼，就需要修改B的代碼，還要重新編譯，這對於大型的系統來說，需要起來代價是很大的。為了達到高內聚低耦合的需要，我們應該讓B依賴於抽象而不是具體。比較常用的方法是使用工廠模式，如：
interface IA
{
……
}
class A
{
………..
}
class B
{
IA a = Factory.CreateA();
}
那麼需要改變時，只需要發動工廠就行了，這大概就是平時所說的控制反轉吧，由以前的修改B類轉為修改工廠類。但是還是需要修改代碼，當需要擴展新的類時也要修改工廠類，這明顯是換湯不換藥嘛，依賴注入也就應運而生了。
對於依賴注入，我的感覺是就像是打針，需要什麼就往裡面注射什麼。那麼針在哪裡？當然是在配置文件裡了。要實現依賴注入，得修改一下B類，添加Setter方法。
class B
{
IA a = null;
IA A
{
set { a = value; }
}
}
此時，B類中A屬性就可以通過配置文件來注入了，想要A就注入A，想要C就注入C，多方便啊。注入，你可以這樣理解：類是一個封裝體，就把它想象成一個空心的球體吧，Setter方法相當於這個球體的一個小孔，注入也就是把它需要的東西通過這個小孔往裡面塞。
說了這麼多，其實都是在為我下一篇的文章作准備。下一篇文章將發布nstruts2.0，它比先前發布的nstruts1.0有了很大的改進，增加了許多新的元素，並且還支持依賴注入，注入的數據可以是對象，常量，還有集合。這些功能已經能完全滿足項目開發中大部分的需求了。同時，nstruts2.0將會是個很好的學習實例，它設計的思路比較清晰和簡單，對象框架設計感興趣的朋友都會有或多或少的幫助。在發布之前，大家可以先看下我先前發布的nstruts1.0，了解一下大概。
