没有合适的资源?快使用搜索试试~ 我知道了~
基于.NET平台的分层架构实战.docx
1.该资源内容由用户上传,如若侵权请联系客服进行举报
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
版权申诉
0 下载量 65 浏览量
2022-01-12
15:36:35
上传
评论
收藏 379KB DOCX 举报
温馨提示
试读
64页
基于.NET平台的分层架构
资源推荐
资源详情
资源评论
基于 平台的分层架构实战
一综述
为了让朋友们把主要精力放在理解分层架构而不是案例本身,我准备选择一个相对简
单的留言本系统作为 ,这个系统的名字就叫做 。
初步计划将这个文章系列分为以下几篇:
综述
系统需求分析及数据库设计
架构概要设计
实体类的实现
接口的设计与实现
依赖注入及 的设计与实现
数据访问层的第一种实现——动态生成 语言
!数据访问层的第二种实现—— "#"存储过程
$数据访问层的第三种实现——基于 %" 框架的 &'( 实现
)业务逻辑层的实现
表示层的实现
使用 *+, 框架对表示层进行改进
总结
这个文章系列不会对所用到的技术进行详细讲解,具体请参考相关文献,阅读文章前
最好能对以下技术有一个了解:
-语言
*
设计模式
关系数据库基础知识
软件架构基本原则与软件工程基础知识
基于 %" 框架的 &'( 技术
+%#%"./01%2
!*+, 框架(特别是客户端编程)
$3( 00标准化布局
(二)需求分析与数据库设计
在实际的项目中,需求分析和数据库的设计是很重要的一个环节,这个环节会直接影响项
目的开发过程和质量。实际中,这个环节不但需要系统分析师、软件工程师等计算机方面
的专家,还需要相关领域的领域专家参与才能完成。
但是,在这个文章系列中,所要使用的 仅仅是一个例子,而且其业务极为简
单,因此,这里并不是真正的需求分析和数据库设计,而是将 的需求和数据库罗列
至此,使朋友们对 有一个大体的了解,方便后续文章中开发过程的理解。
需求分析:
这个项目是一个留言本,其业务极为简单,现将其描述如下。
任何访问者可以进行留言,留言完成后,不会立即显示正文,而是要经过管理员验
证后才可显示。
任何访问者可以对留言发表评论,未通过验证的留言不可以评论。
管理员可以对留言进行回复(这个回复不同于评论,是直接显示在正文下面,而且
是一个留言只能有一个回复),并可对留言与评论实行删除,以及对留言进行通过验证操
作。
管理员分为超级管理员和普通管理员。超级管理员只有一个,负责对普通管理员实
行添加、删除操作。普通管理员可偶多个,负责对留言的管理,并可以修改自己的登录密
码。
这个项目的用例图如下:
图
数据库设计:
设计数据表之前,首先进行实体和关系的识别与确定。
通过需求分析,可以观察得出,本项目的实体有:管理员(不包括超级管理员),留
言,评论。本项目的关系有:留言与评论间的一对多关系。
进一步,数据库各表的设计如下:
管理员表(4.5)
666.5666管理员 66677666主键,自增
%666#%"8%")666登录名 77
*%9"4666#%"8%")666登录密码 77666使用 ( 加密
留言表((%:)
666.5666留言 66677666主键,自增
%666#%"8%")666留言者用户名 77
%.7666#%"8%"))666留言者 ;%.766677
556662666留言内容 77
.6664%.666发表留言时间 77666
'/7<6662666回复 77
*%666#%"8%")666是否通过验证 77
评论表(5)
556662666评论内容 77
.6664%.666发表评论时间 77
(%:666.5666所属留言的 666外键
(三)架构概要设计
本文主要是对将要实现的架构进行一个总体的描述,使朋友们对这个架构有个宏观上的认
识。这篇文章理论性的东西会偏多一点,从下篇开始,将进行实际项目的开发。这篇文章
的许多内容摘自我的毕业论文。
架构基本原则:
这里,将描述一些在这个架构设计中的基本原则,其中很多都是经典的设计原则,不
过针对分层架构的特点,用我自己的语言进行了描述。其中也有我自己提出的原则。
逐层调用原则及单向调用原则
现在约定将 层架构的各层依次编号为 、、…、=、…、;、,其中层的编号
越大,则越处在上层。那么,我们设计的架构应该满足以下两个原则:
第 =(
如果 * 层依赖 层,则 * 的编号一定大于 。
其中第一个原则,保证了依赖的逐层性,及整个架构的依赖是逐层向下的,而不能跨
层依赖。第二个原则,则保证了依赖的单向性,及只能上层依赖底层,而不能底层反过来
依赖上层。
针对接口编程,而不是针对实现编程
这里所指的接口,不是特指编程语言中的具体语言元素(如 -中由 5">% 定义的语
言接口),而是指一种抽象的,在语义层面上起着接合作用语义体。它的具体实现,可能
是接口,可能是抽象类,甚至可能是具体类。
我认为,从不同的视角,接口可以有以下两种定义:
接口是一组规则的集合,它规定了实现本接口的类或接口必须拥有的一组规则。体
现了自然界“如果你是……则必须能……”的理念。
接口是在一定粒度视图上同类事物的抽象表示。注意这里我强调了在一定粒度视图
上,因为“同类事物”这个概念是相对的,它因为粒度视图不同而不同。
具体到 层架构中,针对接口编程的意义在部分上是这样的:
现仍约定将 层架构的各层依次编号为 、、…、=、…、;、,其中层的编号越大,
则越处在上层,那么第 = 层不应该依赖具体一个 =; 层,而应该依赖一个 =; 层的接口,
即在第 = 层中不应该有 =; 层中的某个具体类。
依赖倒置原则
在软件设计原则中,有一种重要的思想叫做依赖倒置。它的核心思想是:不能让高层
组件依赖底层组件,而且,不管高层组件和底层组件,两者都应依赖于抽象。
那么,这个原则和我们上面的原则是否矛盾呢?其实并不矛盾。
因为这个原则定义中的“依赖”是指“具体依赖”,而上面定义中的依赖全部指“抽象依赖”。
我对这两种依赖的定义如下:
具体依赖——如果 * 层中有一个或一个以上的地方实例化了 层中某个具体类,则说
* 层具体依赖于 层。
抽象依赖——如果 * 层没有实例化 层中的具体类,而是在一个或一个以上的地方实
例化了 层中某个接口,则说 * 层抽象依赖于 层,也叫接口依赖于 层。
从这两个定义可以看到,所谓的依赖倒置原则,正是上面提到针对接口编程,而不是
针对实现编程,两者在本质上是统一的。
综上所述,可以看出,本课题设计的分层架构,应该是这样一种架构:
层架构的各层依次编号为 、、…、=、…、;、,其中层的编号越大,则越处在
上层。
架构中仅存在一种依赖,即第 = 层接口依赖第 =; 层,其中
封装变化原则
封装变化的原则定义为:找出应用中可能需要变化之处,把它们独立出来,不要和那
些不需要变化的代码混杂在一起。
开放;关闭原则
开发;关闭原则定义为:对扩展开放,对修改关闭。
具体到 层架构中,可以描述为:当某一层有了一个新的具体实现时,它应该可以在
不修改其他层的情况下,与此新实现无缝连接,顺利交互。
剩余63页未读,继续阅读
资源评论
猫一样的女子245
- 粉丝: 93
- 资源: 2万+
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功