服务层：

代码 

public interface IEmployeeServices
    {
        List<Employee> GetAllEmplyees();
    }
    public class EmployeeServices : IEmployeeServices
    {
        public List<Employee> GetAllEmplyees()
        {
            EmployeeBL employeeBL = new EmployeeBL();
            return employeeBL.GetAllEmplyees();
        }
    }

客户端的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

转载：http://www.cnblogs.com/yanyangtian/archive/2010/05/23/1741908.html

本文链接：http://www.blueidea.com/tech/program/2010/7750.asp　

出处：博客园
责任编辑：bluehearts

上一页 .NET分布式架构开发实战(一) [1] 下一页

◎进入论坛网络编程版块参加讨论