接上文
ILFW框架以最底層為基礎，層層堆疊，上層一依賴於下層提供的服務，並實現其派發的接口，形成完整的FrameWork，不過由於時間原因，有些 Provider之間的聚合偏高，例如AppLogProvider在使用數據庫做為記錄介質時，已經和DataProvider綁定，並不能使用第三方的數據引擎。
ILFW共有18個命名空間，分別管理著這些Provider的主要方法以及各種類庫、接口，每個命名空間並非獨立，正如上圖表示的一樣，所以如果你希望使用ILFW的某一個Provider，可能需要引入幾個dll。
命名空間名稱列表：
表 1.1 命名空間
ILFW將每一個Provider分為功能、枚舉以及配置，每一個Provider都是遵從這個契約開發的，同時這也是命名空間的劃分規則。
“功能”命名空間表示該Provider的主體完成任務，“功能”命名空間會包括接口、抽象類以及對這些抽象元素的實現，它是Provider的主體部分。
“枚舉”命名空間表示Provider中所有用到的需要與用戶交互的數據類型。
“配置”命名空間表示Provider需要配置文件支持的信息部分，Provider運行前，系統會自動加載相應的配置文件，並加載相關節點，將這些節點內的信息提供給“功能”模塊進行處理。
圖 1.2 命名空間結構
結合本人多年經驗總結，將系統開發中重用較多的部分和團隊協作開發時較難控制的部分，以面向對象方式封裝，形成一套業務無關的底層架構(ILFW)，ILFW具有如下優勢：
三層結構分層明顯，程序結構易懂，可擴展性強。
系統較核心的業務驅動層與ILFW皆采用面向對象原則設計，利用繼承、多態等方式，結合接口，增強“驅動的可擴展性”，上層只需繼承或實現相關類或接口，即可對現有底層方法進行擴展。
具有組件的模塊化，靈活和重用性高。
由於ILFW分別面向數據、存儲、安全進行抽象與封裝，業務層面通過配置相關節點並調用方法的方式完成相關業務，所以這種方式增強業務層面的代碼的簡捷易懂性，降低了耦合，執行模塊的功能或與模塊交流信息只通過調用公有接口來實現
開發人員減輕重新建立解決復雜問題方案的負擔和精力。
軟件產品的後期運行維護是個巨大的工程，單純從前期開發時間上考慮其開發效率是不理智的，也是不公平的。采用ILFW架構，則可提升開發效率，一些復雜的外圍控制代碼，之需要用簡短的內部方法處理，對表現層的修改即使發生錯誤，也絕對不會將錯誤擴展到業務邏輯層，更不會影響持久層。
ILFW以Provider的方式提供給程序人員使用，不同的Provider代表不同的封裝，可以完成不同的任務，同時各個Provider之間還會互相調用。
