快捷搜索:

关于代码组织的一些看法(1)<BR><strong>原始需求

本日看了一个篇关于架构的文章,略有所感,记录一下。

软件的架构基础是从一个原始需求启程,慢慢构建可掩护、更机动的开拓框架的历程,在这个构建历程中可能会徐徐的增添代码的繁杂度来满意机动性的要求,从这个层面来讲,繁杂度和机动性生成便是对立的,怎么平衡二者的关系,斟酌到光阴繁杂度,资源等等身分,则蜕变成一门学问,就叫软件工程。以例子来阐明呢会加倍的清晰。

原始需求,基础法子

我们常常会办理一个问题,比如说我们为了方便给自己定了一个义务列表,在记录义务并可以查看义务状态,还可以变动和删除义务。办理这个需求不难想出一个数据表即可办理:

TaskList{

ID,--编号

Task,--义务名称

AwokeTime,--提醒光阴

State --状态}

假定我是在WEB上操作,那么我想完成上述的几个需求,只必要如下几个措施

这是最基础的代码了,在一个webform的页面代码中即可以完成所有需求了,经由过程webconfig设置设置设备摆设摆设来改变数据库办事器的位置,经由过程一个简单的ExcuteSql措施来履行所有对数据库的操作。完成这个义务列表的功能,此时我们只必要一个aspx页面即可,可为什么还必要分那么多层呢。

"我想在Winform也能用"

做软件是为了给人办理问题的,人家就爱用winform的,怎么办,再来个winform的吧,好的,到这里一个软件有两个展现要领,若何办理呢,你在想从新将代码拷贝过来写一个类似web的form吗?那样的话会呈现两个如出一辙的insert措施,update措施等等,今后篡改的话,假如用户有很多的界面展现要领,你要一个个都改吗?那么代码重用的问题呈现了,将这些措施自力出来,一份代码web能用,winform也能用,假如想改动此中的某个措施,直接改便是了,代码的独一性,真不错。

Win form----- web form

\\//

insert,update,delete,search

代码怎么组织呢,我们可以再写一个类DB.CS,

里面有增编削查四个措施,然则数据操作措施是自力出来了,两种用户界面怎么办呢?大年夜家都知道,winform和webform是必要建立两种项目的,那么我们只有将这个数据操作类在自力出来的根基上封装成法度榜样集共两个项目合营引用了,于是,有了下面的转变

---》》

这些简单的建立了一个对照轻易改动数据操作部分和界面部分的模型。

“我们抉择采纳Oracle来存储数据”

软件嘛,需求的变化早已不再是新闻,客户可能已经有一个数据库,为什么要再投入那么大年夜的资源去适应软件呢?试想一下,假如这个需求在前期并不明确,后期一旦篡改我们开拓职员将会多么被动,于是,我们可以做好预留,可问题是假如要篡改数据操作措施,那么Architect.DB层的代码都要篡改,难道我们要将整个代码重写一遍吗?不!我们是法度榜样员,我们可以使用接口做另一套实现即可,如我们可以在某个地方轻松的将”SQL”改为”Oracle”即可让法度榜样替换数据库多好啊,是的我们可以这样做,一个接口,两种实现,根据设置设置设备摆设摆设不合来选择不合的实现要领。

这样我们就可以根据设置设置设备摆设摆设的不合去动态的选择不合的实现,今后假如再有ACCESS的需求也不用怕,直接在加个实现就可以了,在类UserDBO中我们可以根据不合的前提来实例化两个不合的操作类。这样就实现了不合的数据库造访类,平日我们不会将这两种实今世码放到一个类中,分开治理加倍方便,于是便有了下图

此时我们有了两种数据库的兼容要领,可以加倍方便的替换数据库了,然则实际开拓中的数据库造访类要繁杂的多,以是很多时刻我们会将数据造访接口和数据库的操作类分开,变成这样

这样做的好处是各个层面上的代码组织对照清晰,没有萦绕纠缠到一路,异常便于对各层的改动.然而代码组织到这里,是不是就完成了呢,刚开始看petshop的代码时,我也感觉分层有些太多了,但后来真的打仗了对照多的开源代码后,发明是有事理的,下一篇随笔我将会继承写代码组织方面的一些小我看法,包括营业逻辑,缓存和面向办事等等,盼望能跟大年夜家交流。

您可能还会对下面的文章感兴趣: