架构
Martin Fowler 给"架构"这个词做了两点归纳: 1.最高层次的系统分解 2.系统中不易改变的决定
它包括了一些开发者希望能够及早做出的决定,因为这些决定看起来是难以改变的. 如果发现一些决定并不像你想象的那么难以改变,那么他就不再与架构相关.这么下去,架构自然就浓缩成了一些重要的东西.
在架构模式中,层次是最为重要的,Martin Fowler的<<企业应用架构模式>>全书都在阐释怎么将企业应用组织成不同的层次,还有这些层次如何协同工作.
架构和模式
其实二者没有严格的区分标准,我们依照架构的"不可轻易改变"抽取出了一部分模式来作为架构,其余的模式作为辅助,帮助架构的实现.这个和前面的说法很相似,因为"是否架构相关往往带有主观性"
企业应用
这里所提到的架构只是适合企业应用的,给企业应用下做几条标准就是: - 涉及到持久化数据 - 涉及到大量数据及其处理 - 涉及到很多人同事访问数据 - 涉及到大量操作数据的用户界面 - 与散布在企业周围的其他企业应用集成
业务逻辑
说是逻辑,其实是最没有逻辑的地方,因为系统中的逻辑并非取决于人们平时的认知,而是来自客户的要求,而客户的要求总是千奇百怪的
硬件提升可以解决的问题,就不要交给软件
软件人员的代价,和以后可能带来的问题,比硬件要复杂的多
层的基本概念和演化
在分解复杂的软件系统时,设计者用的最多的技术之一就是分层.你一定对大学里面的网络分层还有印象,依照不同的标准,我们有个七层网络模型 或者五层网络模型 ,到后来参加工作,听到网络专业的同学们会说:我们是在XX层工作的
分层的好处可以归纳为以下几点: - 每一层都可以分配人员进行工作,他们可以不用了解其他层的细节 - 可以替换某个层的实现 - 一个层次一旦构建好,就可以为其他层次工作.可复用性强
当 然,事情都是两面的,分层的缺点是: - 一个层不能封装好所有的东西.修改一个层,可能会造成级联式的修改,比如,我们在用户界面(表现层)上增加一个要显示的数据,就必须在数据库中增加对应的 字段(持久层) - 层次太多会影响性能 层级之间传递数据是链式的,每个层都会把数据从一种形式转换到另一种形式,层次越多,处理就越多
分层架构中,最困难的问题 - 建立哪些层次? - 每一层的职责?
层次的起源和进化
一层架构
额,自己从来没见识过这种应用...
两层架构
现在企业的应用基本是无法脱离网络的,那么这就造成了天生的两层 客户端层 和 服务器层 如果应用仅仅是对数据的简单显示和修改,那么这种两层架构还是能够胜任工作的. 但是问题来自:每个企业应用都存在所谓的业务逻辑:比如验证,计算,数据的自定义处理等.
一种思路是把这种逻辑分给两层架构的客户端,这样会很笨拙,并且往往导致把业务逻辑和用户界面耦 合起来,随着业务逻辑的不断复杂,这些代码将越来越难以使用.
另 一种思路是把这些逻辑放到数据库端,作为存储过程.但是存储过程只能提供有限的结构化机制,这将再次导致笨拙的代码.还有,很多人喜欢关系型数据库的原因 之一是:SQL是一个标准,这允许他们更换数据库厂商,虽然很少有人更换.但是存储过程是数据库厂商私有的,那么,普通用户就被剥夺了更换厂商的可能性.
三层架构
基于以上的问题,一个新的层次便应运而生:业务逻辑层 它成为系统中真正的核心
三层架构的层次和职责
| 层次 | 职责 |
|---|---|
| 表现层 | 1.显示信息(界面)2.与用户互动(触摸)3.接收信息(加速计等) |
| 业务逻辑层 | 处理业务逻辑 |
| 数据源层 | 与数据库,云端,文件等交互,实现数据的持久化 |
深入一点说,表现层就是提供一个本应用的接口给别人(或者别的应用)使用,而数据源是使用别的应用的服务(比如数据库软件)
对每个层的依赖性,有一个普遍的原则: 业务逻辑层和数据源层绝对不要依赖表现层 就是说,在业务逻辑层和数据源层的代码中,不要出现调用表现层代码的情况.这个原则将简化在相同基础上,替换表现层的代价,也使得表现层的修改所带来的连锁反应尽量小.
在 使用业务逻辑层的时候,其中一个最复杂的困难就是:什么是业务逻辑,什么是其他逻辑.Martin对这个问题提出了一个不太正规的测试方法:设想向系统中 添加一个全新的分层,比如向web应用增加一个命令行界面层.如果在这个过程中,发现需要重复实现某些功能,那么就说明一些本应该在业务逻辑层实现的代 码,放到了表现层中了.