.NET 分布式架构开发实战之一 故事起源
2010-05-23 09:10
357 查看
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
所有,转载请标明出去和作者。
.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
所有,转载请标明出去和作者。
相关文章推荐
- [原创].NET 分布式架构开发实战之一 故事起源
- .NET 分布式架构开发实战之一 故事起源
- [原创].NET 分布式架构开发实战之一 故事起源
- [原创].NET 分布式架构开发实战之一 故事起源
- [.Net码农].NET 分布式架构开发实战 之 故事起源
- .NET分布“.NET研究”式架构开发实战之一 故事起源
- 一起谈.NET技术,.NET分布式架构开发实战之一 故事起源
- 一起谈.NET技术,.NET 分布式架构开发实战之三 数据访问深入一点的思考
- [原创].NET 分布式架构开发实战之三 数据访问深入一点的思考
- .NET 分布式架构开发实战之二 草稿设计“.NET研究”
- .NET 分布式架构开发实战之四 构建从理想和实现之间的桥梁(前篇)
- .NET 分布式架构开发实战
- .NET 分布式架构开发实战之一
- [原创].NET 分布式架构开发实战之二 草稿设计.NET 分布式架构开发实战之二 草稿设计
- [原创].NET 分布式架构开发实战之四 构建从理想和实现之间的桥梁(前篇)
- .NET 分布式架构开发实战之一
- [原创].NET 分布式架构开发实战之二 草稿设计
- .NET 分布式架构开发“.NET研究”实战之三 数据访问深入一点的思考
- .NET 分布式架构开发实战之三 数据访问深入一点的思考
- .NET 分布式架构开发实战之二