• 一起谈.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中就调用了提供的方法。

      客户端的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 分布式架构开发实战之二 草稿设计

                        .NET 分布式架构开发实战之三 数据访问深入一点的思考

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

  • 相关阅读:
    Chrome开发者工具中Elements(元素)断点的用途
    最简单的SAP云平台开发教程
    Java实现 LeetCode 495 提莫攻击
    Java实现 LeetCode 494 目标和
    Java实现 LeetCode 494 目标和
    Java实现 LeetCode 494 目标和
    Java实现 LeetCode 493 翻转对
    Java实现 LeetCode 493 翻转对
    Java实现 LeetCode 493 翻转对
    Java实现 LeetCode 492 构造矩形
  • 原文地址:https://www.cnblogs.com/waw/p/2163023.html
Copyright © 2020-2023  润新知