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

时间 2019-11-30

原文原文链接

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

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

　　系列文章连接:架构

[原创].NET 分布式架构开发实战之一故事起源app

[原创].NET 分布式架构开发实战之二草稿设计框架

[原创].NET 分布式架构开发实战之三数据访问深刻一点的思考分布式

[原创].NET 分布式架构开发实战之四构建从理想和实现之间的桥梁(前篇)ide

[原创].NET 分布式架构开发实战五 Framework改进篇post

[原创].NET 业务框架开发实战之六 DAL的重构url

[原创].NET 业务框架开发实战之七业务层初步构想spa

[原创].NET 业务框架开发实战之八业务层Mapping的选择策略

[原创].NET 业务框架开发实战之九 Mapping属性原理和验证规则的实现策略

[原创].NET 业务框架开发实战之十第一阶段总结，深刻浅出，水到渠成（前篇）

[原创].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的，而是用来解决问题，这就是技术的价值。

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

　　谢谢你们：）

　　下篇文章：.NET 分布式架构开发实战之二草稿设计

　　欢迎你们参加企业级项目开发团队

　　版权为小洋和博客园全部，转载请标明出处给做者。

　　http://www.cnblogs.com/yanyangtian

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

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