自然框架,拆分后的项目关系

简介:   拆分了一下自然框架,似乎又绕回去了。以前是多个项目分开放的,有人说太分散了,还得一个个下载,麻烦。于是就做了一个解决方案,把项目都放在了一起。     现在呢,QuickPager分页控件比较完善了,有人只想看分页控件的代码,其他的不想看,东西太多了乱。

 

  拆分了一下自然框架,似乎又绕回去了。以前是多个项目分开放的,有人说太分散了,还得一个个下载,麻烦。于是就做了一个解决方案,把项目都放在了一起。

 

  现在呢,QuickPager分页控件比较完善了,有人只想看分页控件的代码,其他的不想看,东西太多了乱。想一想也是,那么就拆分一下吧。原来自定义控件都是放在一个项目里的,编译后生成一个dll,版本号也只有一个。这样版本号就很难管理了,有任何一个控件升级,整个版本号都要升级,因为就是一个版本号。这样版本号就不大够用了。所以以前的源码下载,我只写上传日期而没有写版本号。

 

  拆分之后呢,QuickPager自己是一个项目,可以用自己的版本号而不受其他控件的影响了。这样也是便于维护。

 

  那就拆分吧,不过一拆分问题就出来了。原来放在一起,都好好的。但是一拆分出来就发现出现了互相引用的情况,头疼。怎么办呢?多拆出来几个项目吧。于是自然框架就拆成了10个项目。原来只有六个项目,拆出来一个分页控件和分页算法,应该是八个。就是说又多出来两个项目。一个是基础控件,一个是控件接口。作为接口定义,如果不单独生成一个dll的话,那还真不好引用。不过这还没完,元数据的部分还是没有弄好,这里似乎也应该定义一个接口,可是现在的实力还定义不好。所以你会发现QuickPager分页控件也需要引用这个元数据的项目。

 

  发几个图,这几个图都是比较乱的,我是尽量理顺了,但是还是很乱的感觉。

 

  项目层次图:共用函数作为最底层,数据访问函数库、控件接口、分页算法、登录用户作为第二层的底层,分页控件、基础控件、元数据控件作为控件层,元数据(定义和加载)作为后盾。页面基类就是页面级的了。

  

 

 

项目引用关系:这个就更乱了,尽量避免循环引用和互相引用,现在是完全避免了,但是引用关系还是比较复杂。看来功力还是不够哇。

 

 

 

 

 

基础控件就是Textbox、DropDownList这类的控件

元数据控件,就是必须使用元数据才能运行的控件,比如表单控件、查询控件、数据显示控件。

 

 

相关文章
|
编解码 数据可视化 Java
3D模型拆分与合并展示,IVX真的可以简单实现
iVX 平台的优势和特点,包括逻辑完备性、操作流畅性、面向对象设计方法、可独立作为编程语言等方面的优势,下面来详细的介绍介绍。
123 0
|
3月前
|
设计模式 测试技术
工程代码编写问题之需求的拆分和组合如何解决
工程代码编写问题之需求的拆分和组合如何解决
20 1
|
4月前
软件研发核心问题之在需求拆解过程中,“数据与UI如何关联”的问题如何解决
软件研发核心问题之在需求拆解过程中,“数据与UI如何关联”的问题如何解决
|
4月前
|
数据库
业务系统架构实践问题之当一个模型既有独立性又有与其他模型的关联时,判断它是否为聚合根问题如何解决
业务系统架构实践问题之当一个模型既有独立性又有与其他模型的关联时,判断它是否为聚合根问题如何解决
|
4月前
|
设计模式 算法 开发者
软件复用问题之区分「不重复」和「复用」,如何解决
「不重复」和「复用」之间有何区别软件复用问题之区分「不重复」和「复用」,如何解决
|
4月前
|
存储
业务系统架构实践问题之聚合根和其附属模型之间有什么约定
业务系统架构实践问题之聚合根和其附属模型之间有什么约定
|
关系型数据库 数据库
数据库原理与应用系列_05关系模式的分解
定义:无损联接分解是将一个关系模式分解成若干个关系模式后,通过自然联接和投影等运算仍能还原到原来的关系模式,则称这种分解为无损联接分解。
数据库原理与应用系列_05关系模式的分解
|
SQL 缓存 JSON
任务分解与函数拆分以及面向未来编程的思想分享
任务分解与函数拆分以及面向未来编程的思想分享
252 0
任务分解与函数拆分以及面向未来编程的思想分享
|
iOS开发
[译] 伟大设计与好设计之间区别是什么?这里告诉你真相
能否举一些伟大设计的例子?发表评论与我们一起分享吧。
1132 0
|
数据库 索引 大数据
这才是真正的表扩展方案
事情变得有意思了,上一篇花1小时撰写的“一分钟”文章,又引起了广泛的讨论,说明相关的技术大家感兴趣,挺好。第一次一篇技术文章的评论量过100,才知道原来“评论精选”还有100上限,甚为欣慰(虽然是以一种自己不愿看到的方式)。
659 0