.NET 分布式架构开发实战之一 故事起源

body {padding:0;margin:0;}

.NET 分布式架构开发实战之一 故事起源

 

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

 

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

       新人 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();
        }
    }

 

 

       服务层：

      

       

 

代码

     public   interface  IEmployeeServices
    {
        List < Employee >  GetAllEmplyees();
    }


     public   class  EmployeeServices : IEmployeeServices
    {
         public  List < Employee >  GetAllEmplyees()
        {
            EmployeeBL employeeBL  =   new  EmployeeBL();
             return  employeeBL.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的，而是用来解决问题，这就是技术的价值。

 

       本系列文章就展示整个构思，设计，实现的过程。本系列文章所要开发的项目的价值可能不大，本系列文章的价值在于架构的思考和设计过程，一步步的演化过程。  　　

　　谢谢大家：）

 

 

　　 版本规个人和博客园,csdn 所有，转载请标明出去和作者。