ASP.NET企业开发框架IsLine FrameWork系列之二--命名空间与契约

 接上文

    ILFW框架以最底层为基础,层层堆叠,上层一依赖于下层提供的服务,并实现其派发的接口,形成完整的FrameWork,不过由于时间原因,有些Provider之间的聚合偏高,例如AppLogProvider在使用数据库做为记录介质时,已经和DataProvider绑定,并不能使用第三方的数据引擎。

    ILFW共有18个命名空间,分别管理着这些Provider的主要方法以及各种类库、接口,每个命名空间并非独立,正如上图表示的一样,所以如果你希望使用ILFW的某一个Provider,可能需要引入几个dll。

    命名空间名称列表:

表 1.1 命名空间

ASP.NET企业开发框架IsLine FrameWork系列之二--命名空间与契约 

 

    ILFW将每一个Provider分为功能、枚举以及配置,每一个Provider都是遵从这个契约开发的,同时这也是命名空间的划分规则。

    “功能”命名空间表示该Provider的主体完成任务,“功能”命名空间会包括接口、抽象类以及对这些抽象元素的实现,它是Provider的主体部分。

    “枚举”命名空间表示Provider中所有用到的需要与用户交互的数据类型。

    “配置”命名空间表示Provider需要配置文件支持的信息部分,Provider运行前,系统会自动加载相应的配置文件,并加载相关节点,将这些节点内的信息提供给“功能”模块进行处理。

 

ASP.NET企业开发框架IsLine FrameWork系列之二--命名空间与契约

图 1.2 命名空间结构

    结合本人多年经验总结,将系统开发中重用较多的部分和团队协作开发时较难控制的部分,以面向对象方式封装,形成一套业务无关的底层架构(ILFW),ILFW具有如下优势:

  1. 三层结构分层明显,程序结构易懂,可扩展性强。

    系统较核心的业务驱动层与ILFW皆采用面向对象原则设计,利用继承、多态等方式,结合接口,增强“驱动的可扩展性”,上层只需继承或实现相关类或接口,即可对现有底层方法进行扩展。

  1. 具有组件的模块化,灵活和重用性高。

    由于ILFW分别面向数据、存储、安全进行抽象与封装,业务层面通过配置相关节点并调用方法的方式完成相关业务,所以这种方式增强业务层面的代码的简捷易懂性,降低了耦合,执行模块的功能或与模块交流信息只通过调用公有接口来实现

  1. 开发人员减轻重新建立解决复杂问题方案的负担和精力。

    软件产品的后期运行维护是个巨大的工程,单纯从前期开发时间上考虑其开发效率是不理智的,也是不公平的。采用ILFW架构,则可提升开发效率,一些复杂的外围控制代码,之需要用简短的内部方法处理,对表现层的修改即使发生错误,也绝对不会将错误扩展到业务逻辑层,更不会影响持久层。

    ILFW以Provider的方式提供给程序人员使用,不同的Provider代表不同的封装,可以完成不同的任务,同时各个Provider之间还会互相调用。


本文转自Aicken(李鸣)博客园博客,原文链接:http://www.cnblogs.com/isline/archive/2009/12/17/1626503.html,如需转载请自行联系原作者

上一篇:《卸甲笔记》-PostgreSQL和Oracle的SQL差异分析之一:外连接


下一篇:《卸甲笔记》-PostgreSQL和Oracle的数据类型的对比系列四:大数据类型