本系列文章是為那些准備或已經開發定制開發框架的人士准備。由於工作關系，計劃一到兩周出一篇文章，為每一位愛好設計或類庫開發的人士提供批評、討論的地方。鑒於Java下的各類框架層出不窮，這次代碼部分就用.Net來說事兒。當然，不看代碼部分此文一樣可以作為其它語言程序員批評與討論的地兒。因本人水平有限，僅以最簡單的代碼來說明最簡單的應用，希望能讓您在簡單的應用中獲得不簡單的靈感。
目錄如下：
設計自己的應用開發框架一(引子)
設計自己的應用開發框架二(體系結構)
設計自己的應用開發框架三(數據操作與業務實體)
設計自己的應用開發框架四(業務類庫與業務邏輯)
設計自己的應用開發框架五(插件編寫與用戶界面)
設計自己的應用開發框架六(異常與日志)
設計自己的應用開發框架七(國際化)
設計自己的應用開發框架八(插件化)
進正題
像本文摘要所說，如果您或您的公司不是只做一次的應用軟件、或者說不是只做很短一段時間的應用軟件。又或者您想把自己的互聯網產品都寫成facebook那麼易擴展豈不會很cool？那麼如題，你需要一個能夠快速進行應用開發的定制框架。
什麼樣的框架？
就是總能夠幫助你完成很多工作，並不拘泥於只用來一次開發的東東。這個定義聽起來更像是一個大類庫。當然，它還要承擔起支撐整個軟件的骨架的作用，不但提供諸多健壯的.Net framework或JVM沒有的常用功能，還要對整個開發過程做到有效控制。
怎樣快速？
您或您的公司所擅長的開發方向是什麼您一定比我清楚，擅長的通常也是最常用的。不同的項目總要用到相同的技術和代碼片段，那麼為什麼不把他們總結起來，做成通用的開發模塊呢？
為何要易擴展？
為什麼現在刀片服務器都賣的那麼火？因為刀片服務器可以告別更多的電纜、不必為減少能耗而降低性能。那麼我們的軟件開發是不是也應該告別更多的耦合、不必為增加新模塊而降低程序執行效率呢？在應用開發的分層模式中，小規模的軟件並不會引起明顯的耦合和分層不清晰，但是一旦軟件的未來規模會很大，甚至隨時可能添加新模塊，那您有沒有想過使用一種開發模式來限制它？如果只是硬性的規定，會有把這種開發模式寫到框架中來應用來得更妥麼？更何況在全世界推行SaaS的今天，您的日常開發過程中所面臨的更多問題是由擴展和變更帶來的。
是否插件開發?
看過上面這段文字，我堅信你已經希望自己的系統能夠實現易擴展的開發模式了。但是這是後我們通常會面臨另一個問題，那就是是否使用插件開發的形式來組織我們的代碼？當您確信要使用插件形式架構自己的系統的時候，那麼又如何選擇最適合自己的架構方式呢？在此系列文章的最後部分，將闡述我對插件開發的一點兒想法。
那麼好，為了讓我們不再重復勞動、分層更清晰、代碼的耦合更低、更易於擴展、更遵守規則、開發更敏捷，開發一套適合自己的定制開發框架吧^o^
