惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

H
Help Net Security
博客园 - Franky
GbyAI
GbyAI
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
爱范儿
爱范儿
IT之家
IT之家
酷 壳 – CoolShell
酷 壳 – CoolShell
aimingoo的专栏
aimingoo的专栏
博客园_首页
MongoDB | Blog
MongoDB | Blog
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
Recent Announcements
Recent Announcements
Scott Helme
Scott Helme
有赞技术团队
有赞技术团队
M
MIT News - Artificial intelligence
C
CERT Recently Published Vulnerability Notes
K
KPMG report finds enterprise disconnect between AI and its ROI | CIO
Jina AI
Jina AI
F
Fortinet All Blogs
N
Netflix TechBlog - Medium
L
LangChain Blog
L
LINUX DO - 最新话题
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
H
Hacker News: Front Page
MyScale Blog
MyScale Blog
P
Palo Alto Networks Blog
G
Google Developers Blog
Google DeepMind News
Google DeepMind News
AI
AI
T
Troy Hunt's Blog
Microsoft Azure Blog
Microsoft Azure Blog
阮一峰的网络日志
阮一峰的网络日志
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
Vercel News
Vercel News
Microsoft Security Blog
Microsoft Security Blog
罗磊的独立博客
S
Secure Thoughts
大猫的无限游戏
大猫的无限游戏
博客园 - 叶小钗
人人都是产品经理
人人都是产品经理
Blog — PlanetScale
Blog — PlanetScale
博客园 - 司徒正美
Apple Machine Learning Research
Apple Machine Learning Research
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
博客园 - 三生石上(FineUI控件)
S
Security @ Cisco Blogs
Cloudbric
Cloudbric
E
Exploit-DB.com RSS Feed
Attack and Defense Labs
Attack and Defense Labs

博客园 - 小陆

版本的故事(五)闯关旅程 从技术谈到管理,把系统优化的技术用到企业管理 版本的故事(四)版本号有多重要 版本的故事(三)取个好名字 版本的故事(二)版本的诞生 版本的故事(一)为什么要写版本的故事 程序配置的原则和实践以及 Spring Boot 支持方式 全文检索基本概念 Elasticsearch升级1.5版本暴露jdk的bug 以后还是要多写点博客 DateTime类型的一个Bug 完全命令行.NET开发 .NET初学者架构设计指南(四)Model-View-Controller .NET初学者架构设计指南(三)设计模式 .NET初学者架构设计指南(二)OO设计初次见面 .NET初学者架构设计指南(一)Hello world的时代 无痛苦的软件维护——被遗忘的需求 无痛苦的软件维护——文档和代码 NGOSS的一点简单概念
软件的逻辑层次
小陆 · 2006-12-19 · via 博客园 - 小陆

基本层次

软件的逻辑结构可以划分为下面四个基本层次:

从下往上依次是:

1:基础设施层——这个层次是纯技术层次,解决的是系统的物理问题,比如database gateway、网络通信、对象容器……这个部分与业务需求关系不大,是系统的物理条件。

2:business对象——在这个层次上,业务要素出现了,业务领域中的概念在这里实现。比如一个航运公司的系统,这里就应该有航线、航班、座位、乘客、登机牌……这些对象应该拥有与实际业务领域相符的属性、方法。

3:business流程——这个流程不是指程序解决问题的流程,而是用户的商业活动的流程。他体现的是端到端的业务流程。比如:检票员为旅客办理登机牌。business流程的输入参数是business对象,输出参数是business对象,产生的异常也是business对象。business对象在这里组合、串接,实现业务流程的自动化。这个层次是在直接实现用户的需求。

4:UI和接口——这个层面调用business流程,将执行的结果交给软件的用户,或者别的系统。

这种逻辑层次划分是最基本的情况,各种复杂的层次都是这种方式的一种扩充。比如下面这样的形式:

在基础设施层和business对象之间,加入了一个DAO层。DAO层一方面负责数据的存储,体现了数据的存储方式,另一方面体现了业务对象的属性。这样就使business对象只需要负责纯粹的业务逻辑,不用关心物理问题。简单的说,业务对象里面不需要写SQL语句了。

business对象和business过程之间,加入了Service层。business对象也是具有行为的,但是这样的行为是比较细微的,需要调用者在多次调用之间保持必要的状态,需要用Service层来做一个封装,更明确的表达业务含义。

单元测试

单元测试需要关心一个问题:层次之间的依赖关系。如果要测试某一个层次上的对象,必须同时建立他所依赖的每一个对象。层次之间的依赖越简单,测试越容易。

逻辑层次之间原则上是由上至下的依赖关系,同一层次内部的对象可以互相依赖。跨越层次的调用也是允许的,比如在UI Process中调用Business对象。UI层和UI Process层之间存在着互相的依赖。开发中我们最希望测试的是这三个层次:business过程、service、business对象。我们只要对下层对象建立stub对象,就可以对这三个层次上的对象进行测试。

对这三个层次的测试结果不仅保证了程序的运行时正确性,也是对程序的业务流程进行测试。在开发过程中和维护过程中,某个业务流程发生了变化,可以用单元测试保证其他流程不会受到危害。这样的构架可以保证迭代开发过程。

和物理层次的结合

上面说的都是系统的逻辑层次。在系统中还存在着另一个层次——物理层次。逻辑层次的目的是简化程序的逻辑复杂度,便于开发和维护;物理层次的实现需要考虑实际的物理分布情况,合理的安排每个物理节点的任务,最大限度提高系统的性能。逻辑层次和物理层次的划分依据和划分目的都是不一样的,他们之间存在着联系,但也不是绝对的。

逻辑层次和物理层次的结合有两种方式:

1、在基础设施层解决掉物理分布的问题,建立一个分布式的对象容器,把business对象和service放到容器中。这样,business对象和service就不必处理复杂的物理分布问题,business过程也不必关心他所调用的对象是在什么位置建立的。这样的方式最大限度的减少了物理结构对程序逻辑结构的影响,增加了物理分布的灵活性。但是在大部分情况下,对系统的效率都是有危害的。

2、在business对象内部处理物理分布的问题,或者制定一个技术无关的接口来体现business对象,在各物理节点编写各自的实现。这样物理层次和逻辑层次是搅在一起的,使系统的逻辑结构显得混乱,但是可以达到较高的运行效率。