实战之一 故事起源

前言：本系列文章主要讲述一个实实在在的项目开发的过程，主要包含：提出问题，解决问题，架构设计和各个逻辑层的实现以及新问题的出现和代码的重构。本系列文章以故事的形式展开，而且文章列举的很多项目的名称，大家也不用太关心，很多都是虚拟的。

本篇主要讲述项目的一些背景。

新人Richard被分配到了一个企业自动化信息管理项目组--Automation Information Management Project(后面简称AIM)，当Richard进入项目组的时候，这个项目已经开始了，项目的架构也已经在两周之前构建好了--SOA架构，而且使用的主要技术也敲定了:WCF, Linq.

注：因为项目是首次采用"新技术"(因为以前没有使用WCF,Linq，所以被称为新技术)，项目就这样开始进行了。

半年之后问题就开始出现了(其实问题就一开始就出现了，只是大家还认为问题不大)：因为当初在设计的时候，项目的架构是由项目组的其他两个人设计的，整个项目开发基本上就没有采用面向对象的思想来开发，而且虽然在架构设计上分了：数据层，业务层，服务层，和UI层，但是各层之前是紧紧的耦合，可以说是“牵一发而动全身”：如数据访问层稍微一改，业务层就跟着动，然后改变一层层的开始波及。

大家都开始觉得这样很累，但是项目已经做到这个阶段了，不可能重来。每次新需求一来，项目的的改动可以说是天翻地覆。而且当初设计架构的那位仁兄也就项目一开始的一个月后就走了。

下面的图就展示项目中的架构设计：

咋一看起来还是不错的，一般的架构都是这样设计的。下面就开始讲述它们之间的一些调用关系，看看有什么问题：

数据访问层：

public class EmployeeDAL
    {
        public List<Employee> GetAllEmplyees()
        {
            //...
        }           
    }

其中Employee就是Linq生成的一个实体对象。

业务层：

代码

 public class EmployeeBL
    {
        public List<Employee> GetAllEmplyees()
        {
            EmployeeDAL employeeDAL = new EmployeeDAL();
            return employeeDAL.GetAllEmplyees();
        }
    }

服务层：

代码

然后就是在客户端生成代理，然后在UI中就调用了提供的方法。

现在一个最明显的问题就是：把数据层的数据实体Employee一层层的传递，最后到了客户端的UI代码中，而业务层中的EmployeeBL基本上没有起到什么作用，只是起到一个过渡的作用，只是在Insert ，Update,和Delete的时候，对一些字段进行了相应的Check和Validation，如Email格式是否正确等等。其他的一些流程的Check也是代码的堆积，业务类很"弱"。

总的看起来就是"牵一发而动全身"的效果。

而且在开发过程，分层的好处基本没有体现出来。

在业务类的设计的时候，所有的业务类都显得比较的"弱"，之所以这么说，主要是基于这样的一个思想：

都知道，在面向“对象”设计的过程中，每个类就好比一个人，实例化一个类就好比生成了一个人，这个人可以在一出生就具备很多的能力(天生秉异)，如异常处理，日志跟踪，缓存，通用的验证机制等等；也可以一出生什么都不会(或者只会做最基本的几件事情)。之前的业务类实例化之后就生成一个非常普通的人。每个类都得重写很多的基础代码，说到通用那就只是copy代码。如果想要使得新生成的类很强大，具备很多功能，在设计的时候可以让这些类继承一个功能比较强大的基类。当然继承只是实现方式的一种。

现在Richard已经被分到了另外的一个项目组(也是本系列文章要讲述的一个项目，就称为项目进度管理系统—Project Process Management(PPM))，而且担任了架构的设计和开发(之前的架构设计Richard没有发言权)。有了前车之鉴，在新项目开发之前的几个月，Ricahrd首先就开始了通用架构的设计，目的有两个：

1.解决之前项目的问题：不灵活，不通用，每次都做重复性的事情等。

2.结合自己的考虑，开发一个Framework，使得开发更加的快速，灵活，强大。

其实在项目真正开始了之后，不可能给你几个月的时间去设计架构的。其实在AIM出现问题之后，Richard就已经在构思如果开发一个通用的Framework了（”通用”--不表示就是到处可用，因为公司的一直是开发某一领域软件的，比如现在的公司就擅长开发企业管理的一些软件，所以开发出一个基于领域模型的架构和框架还是有可能的）。Richard也想挽救AIM，由于诸多原因，想法终究只是成了想法。

在从AIM项目出来之后，Richard又开始了另外的一个项目的开发，名称我们暂时就虚拟的称为EMS(Employee Management System),EMS项目不是很大，公司解决让Richard一个人开发这个项目。这个项目给了Richard很多的时间来考虑架构设计和Framework设计的时间，因为EMS项目不是很复杂，而且技术和进度都在掌控之中，在正常上班时间就可以到时候定期交付。所以每天下班之后，Richard开始加班去构思Framework的设计，开发的时间越长，技术就应该沉淀的越多，如以通用类库，组件的方式或者解决问题方案的文档等出现。只有这样，下次的开发才更加的快速。

3个月下来，EMS项目完成了。而且Richard设计的Framework也有了雏形。准确的说，还只能称为 基础架构基本完成。EMS没有采用这个Framework来开发，因为Framework的设计和实现于EMS是同步进行的。

Richard心里是这样认为的：设计通用的架构，然后在项目中不断的锤炼，更新，产生出通用的代码，然后演化为Framework。只有设计出了自己的Framework，以后的开发才有可能进入"光速开发"。

在这个项目开始之初，Richard就和其他几个组员讨论了如何实现，同时也推出了自己开发的成果。商量之后，决定采用Richard的设计。

Richard在设计架构的时候，也参考了现在流行的一个Framework,如Spring.NET ,CSLA.NET, Nhibernate，主要吸收它们的一些思想，同时也分析了这些Framework对自己项目的利弊。而且认为：没有绝对万能的技术，一个架构的实现需要在很多的因素之间权衡，技术不是用来show的，而是用来解决问题，这就是技术的价值。

实战之二 草稿设计

前言：本篇之所以称为草稿设计，是因为设计的都是在纸上完成的。反映了一个思考的过程。

本篇的议题如下：

1. 第一个数据层草图的提出

2. 对数据访问层的思考

3. 第二个数据层草图的提出

1.数据层草图的提出

Richard开始着手设计，一开始他没有就立刻在自己的计算机开始敲代码。而且采用笔＋纸开始构思。

因为他认为：写程序不是什么时候都得上机，脑子里面想什么的才是最重要的，往往很多时候，在设计程序时，首先在头脑中就已经把整个功能已经实现了，甚至代码的详细编写都已经在头脑中走了一遍，并且在头脑中”运行，调试”了。

开始设计了，因为这次Richard想要提出一个比较好的架构，一个比较强大的企业级的架构，所以参看成功的一些案例是很有必要，Richard也就想到了微软best practice的那些推荐的架构组织方式和建议（大家对best practice不熟悉也要紧，不会影响阅读）。

之后，Richard的第一个草图就出来了：

一个架构组织方式的提出，不是随随便便就提出的，新的架构的设计和提出首先必须要明白你要解决哪些问题，而且也不要”过度设计”。(这个过程很难，很多时候需要权衡，所以作为架构的设计者，权衡的思想很重要：在时间，资源，资金等都要考虑)。可能在起初会参看一些别的设计架构，甚至是模仿它们，但是随着思考的深入，那些表象的东西就会逐渐的被抛除。

同时也开始设计的时候，没有说一定要立刻就要设计出一个很强大的东西出来，对架构设计的能力也是在慢慢的演化和思考过程中提升的。

2. 对数据访问层的思考

在解释为什么架构要像上面那副图进行设计之前，我们首先来讨论一些之前项目问题：

对于数据访问层(DAL)的问题：

1. DAL很依赖Linq生成的实体。可以说在之前的项目中，在数据访问层能够使用的技术就已经”钉死”在了Linq上。这里不是说Linq不好，而且强调在DAL的访问技术的选择的余地已经没有了，不灵活。

a) 在架构的设计过程中，就需要考虑到以后技术的转变和更换，可能在项目A中采用Linq to sql，但是在项目B中就采用Entity Framework。因为我们的目的就是要开发一个比较灵活的通用架构，能够支持不同就数据访问技术。可能以后的项目都只是用一种访问技术，但是最为架构的设计者，特别是希望从架构最后能够演化到Framework, 那就要为更换技术预留接口。

2. 在DAL中没有很多的异常处理等底层机制。

a) 在项目设计的过程中，有些底层的机制是几乎每一个逻辑都要用到的：异常处理，日志跟踪，缓存机制，事务机制，安全验证机制。当时在之前的DAL中是没有的。可能现在你认为有些机制不是需要的，或者不明白为什么需要。

因为一个强大的软件，不能随随便便就因为某些异常或者错误就崩溃了，也不可能就是一大堆代码的堆砌。上面所提到的有些机制：如异常，日志，它们的价值很多时候在软件维护的时候体验出来。根据日志记录，可以查处软件哪里出了问题，如是数据库断了，还是哪个操作流程导致了问题。 而有些机制是在运行时体现价值，如缓存，验证，事务。

但是在使用这些底层机制的时候也要权衡，综合的考虑，如缓存机制，就得明白那些数据要缓存，缓存在哪里，缓存数据时候要加密，缓存多长时间，如何刷新过期了的数据。等等，很多东西要考虑。

3. 数据来源仅仅只是考虑了数据库。其实这个问题不是之前的项目的一个问题，但是这里有必要提出。

a) 一般在我们开发项目的时候，数据的来源很多时候都是数据库，我们直接操作数据库就行了，但是还得考虑一个问题：如果我们的项目没有自己的数据库，我们的数据来源是来自其他的公司或者服务接口，怎么办？作为架构的设计者，是需要考虑这些的。

可能在项目敲定那天就已经清楚是自己设计数据库还是从其他地方获取数据。但是一个通用的一个架构的就要能够为其他的数据源预留接口。

这里，可能就有了一点”过度设计”的味道了，起初在项目A中所使用的架构没有考虑其他数据源的问题，但是如果在项目B中出现了，怎么办？那么架构就要演化，改进来适应这种情况。

之前也提过，没有必要一上来就设计强大的就架构，而是在项目中改进，演化。开始时候没有考虑到，以后慢慢的加嘛。(比较的纠结)。

上面只是紧紧的从数据层DAL的角度进行了思考，DAL最终还是为业务层BLL提供数据的，所以就考虑DAL以何种方式来被BLL调用，鉴于之前的一些考虑，可以得出一点：不让BLL直到DAL的实现细节，所以接口似乎是个不错的解决办法，Provider的模式也似乎可以排上用场。

于是,Richard就决定在DAL和BLL之前加上接口层来解耦。

3. 第二个数据层草图的提出

这个图和之前的第一个图基本上是一样的，只是做了一修改，而且加上了之前谈论中涉及的一些问题。

因为随着思考的深入，逐渐的发觉：数据源的来源可以很多—数据库，普通文本，XML等等。不同的数据源提供不同的Provider，其实从其他的服务接口获取数据也是一种来源，上面的图之所以单独的把Service Agent分出，主要是因为比较特殊。

而且图中的那些基本功能：Log, Exception等，是到处都用到的。

此时Richard也在头脑中闪现了一些要处理的，可以出现的异常：

1. Data Source is not exits:数据源不存在，因为这个问题很常见，比如在项目运行过程中，数据库断了，或者远程的服务无法访问，等等基本都属于这个问题的。所以这个异常肯定是要处理的。

2. Time out:超时。这个异常很常见，获取的数据过大，或者远程数据源连接超时，等，都可以引发一些问题。

3. 如果数据源是其他服务接口提供数据，那么在数据获取时，可能要转换数据格式，如果格式出错，。或者发送的数据不符合一些规则，这个异常一定要处理，因为这些数据可能涉及到安全的问题了：是数据真的不正确，还是被篡改了。

程序就必须对这些异常进行处理：是把原生的异常抛出，然后有业务层决定如果处理；还是决定把异常包装称为另外的一个异常，再抛出；还是最后干脆再DAL就执行自己处理，然后给业务层一个友好的提示，等等。如果数据源是远程的服务，那么如果服务断了，在异常过程中，采用什么样的策略：简单的处理，如抛出异常，记录日志，还是做一些恢复性的操作，如尝试重新连接，等。

之前第一张图中，在DAL上定义一个接口，用来接耦，但是在第二张图有做了一些修改－－把DAL做为服务提供出去。之所以做了这个修改，因为在开始思考的时候，只是认为底层设计的DAL只是给BLL使用。可以发觉到一点：在DAL中，数据可以从远程的服务中获取，那么可能我们这里的DAL也可以作为服务给其他的人设计的DAL使用，也就是说，我们的这里的DAL成了远程服务的数据源。所以做了上面的修改。但是这个思考到还会改进，因为这里面问题(读者朋友可以先自己思考是什么问题)。

版权为小洋和博客园所有，转载请标明出处给作者。

http://www.cnblogs.com/yanyangtian