关于代码组织的一些看法（上）

今天看了一个篇关于架构的文章，略有所感，记录一下。

软件的架构基本是从一个原始需求出发，逐步构建可维护、更灵活的开发框架的过程，在这个构建过程中可能会逐渐的增加代码的复杂度来满足灵活性的要求，从这个层面来讲，复杂度和灵活性天生就是对立的，怎么平衡二者的关系，考虑到时间复杂度，成本等等因素，则演变成一门学问，就叫软件工程。以例子来说明呢会更加的清晰。

原始需求，基本办法

我们经常会解决一个问题，比如说我们为了方便给自己定了一个任务列表，在记录任务并可以查看任务状态，还可以更改和删除任务。解决这个需求不难想出一个数据表即可解决：

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的代码时，我也觉得分层有些太多了，但后来真的接触了比较多的开源代码后，发现是有道理的，下一篇随笔我将会继续写代码组织方面的一些个人见解，包括业务逻辑，缓存和面向服务等等，希望能跟大家交流。