接上文
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之间还会互相调用。
本文转自Aicken(李鸣)博客园博客，原文链接：http://www.cnblogs.com/isline/archive/2009/12/17/1626503.html，如需转载请自行联系原作者