ABD——基于架构的开发模式 上海湃睿信息科技有限公司 Bardo QI (祁

宏 )

2010年 7月 30日

© 2010 PISX 2

概要

ABD——基于架构的开发模式，在微软， ADOBE等公司中被使用，在 ACTIONSCRIPT， JAVA语言中作用非凡。奇怪的是在 PHP界却相当落后。

有人说，掌握了 ABD，就能够轻松项目管理，掌握了ABD，就离真正的架构师不远了。那么，你想了解 ABD吗？

本话题为你揭开基于架构的开发模式的秘密，解决代码可读性，可维护性，可扩展性，与程序员的无关性等问题，使你

的项目管理技术更上一层楼，让你走上架构师之路。

© 2010 PISX 3

两种截然不同的结果

…………

统一标准的架构，人人清楚哪个目录是什么，每一个源码文件都是 class

有多少个应用，就有多少种架构

无论大小，架构永远不变应用越是庞大，架构是越是混乱

抄袭，原创，结果只有一个高手，新人，质量相距甚远

程序员风格对程序结构的影响力几乎为零。独立开发，团队如同一人。

程序员风格对程序结构存在较大的影响。结伴编程，仍是正草隶篆。

代码可读性高，与程序员无关性高。代码不具有可读性，与程序员无关性差。

用最简的《编程规范》，但代码仍相当规范

有极为详细的《编程规范》却代码仍不规范

我们最想要的我们最不想要的

© 2010 PISX 4

什么是软件开发模式

软件开发模式的定义包含两方面： 其一是指软件开发中的管理模式，即在软件开发过程中要管理什么，怎样管理。

其二是指软件开发中的操作规范，包括开发流程定义，即按照什么样的步骤来开发软件。

有了敏捷，真的还会这么痛苦吗？ 本主题阐述软件开发模式与架构管理模式之间的关系。并以 PHP应用架构管理为中心，讲述架构管理的沿革， PHP架构管理现状，以及架构管理中一些必要的原则、 PHP大型应用的基本架构等。

时间有限，内容太多，无法进行实例讲解，敬请谅解！

© 2010 PISX 5

新型软件开发模式简介

SCRUM 由 Ken Schwaber和 Jeff Sutherland提出和倡导 敏捷开发模式 sprints短周期循环， scrum会议，以及 burn down graph管理

XP (eXtreme Programming) 由 Kent Beck,Ward Cunningham,Ron Jeffries提出和倡导 TDD与连续性整合 结伴编码

ASD （ Adaptive Software Development）由 Jim Highsmith提出和倡导 speculate,collaborate,and learn（将项目的历程分成 3个阶段：思索、合作、学习

TimeBoxed 时间盒管理 MSF(Microsoft Solutions Framework)由 Randy Miller,Paul Haynes提出，微软倡导 使用者角色 (Personals)推行一个从角色到使用方案的设计流程 单元测试

© 2010 PISX 6

软件开发模式是否足够？

“ ”新型 开发模式普遍被接受并广应用： 基于测试的开发（ TDD）

• 先确定测试，以测试为中心。 敏捷开发模式

• 如前述的 SCRUM， XP开发模式 代码制质量控制：

• code review

• 结伴编程

PHP “ ”使用 新型 开发模式产出的软件？ BUG依旧 可靠性仍然很差 最后期限仍不可预估 与程序员无关性仍不够理想 当需求变更经常仍是牵一发动全身

© 2010 PISX 7

项目管理的两个方面

软件开发模式 它是属于管理层的 是软件工程管理

• 归口：项目经理

软件架构管理 它是属于技术层的 是软件架构与编码管理

• 归口：软件架构师（注：架构师不只是管软件架构，同时还有系统架构）

先下个结论： ——只有敏捷（或者某一天来一个更高级的开发模式） 仍然没用！ 因为还有很多问题解决不了！

© 2010 PISX 8

基于架构的开发模式

ABD——Architecture-Based Development 本概念最早产生于 1999年。

基于架构的开发模式 目标：

• ABC——Architecture-Based Coding(基于架构编码 )

• AOP——面向切面编程（ JAVA中的术语）• ABD主要面向应用的基本架构

再下一个结论： 架构管理比软件开发模式还要重要！

• 原因：架构管理最终是在保证软件质量的前提下，保证工期！ 一个简单场景：

• 小团队，小项目，有架构管理，无敏捷，它有可能成功• 小团队，小项目，无架构管理，有敏捷，它仍不能成功

© 2010 PISX 9

——并非新概念 架构的沿革

ABD基于架构的开发模式 这一概念并非新概念。因为，我们一直在为架构奔走：

• DOC/VIEW（文档 /视图结构）• UML/MDA（Model-Driven Architecture ）• CORBA(通用对象请求体系架构， IDL）• WEB SERVICE（网络服务，WSDL）• MVC

• MTS（Multi-Tier System）• REST（ Representational State Transfer 表述状态转移）• SOA（ Service-Oriented Architecture ）

我们时刻忙于一个概念，但没有考虑我们应用的架构• 其它编程语言不需要• 但 PHP没有它不行！

© 2010 PISX 10

模式管理 VS架构管理

模式管理 你何时完成

你做出来

实现功能，完成测试，无法保证与程序员无关性

架构管理 你何时怎样完成

你必须这样做出来

不仅只要求实现，同时限制了你怎样实现，因而保证了与程序员的无关性

© 2010 PISX 11

都是 PHP惹的祸！！

架构管理随团队产生！随应用的复杂而增强。 MFC——架构：一切都是类， DOC/VIEW分离。 VB6.0，由向导为你产生合理的软件架构。 VS.net——把架构用到的WEB应用之中 JAVA——SSH+(JSF、 Tapestry)的运用是良好架构的保证 ruby——Ruby On Rails 是良好架构的框架

很明显，架构管理， 首先要有好的开发框架。 PHP？？

• zend?

• symfony?

• codeigniter?

• yii?

© 2010 PISX 12

从现有其它语言看架构管理目标

第一：以往是：要有详细的与源程序一致的开发设计文档。“现在的要求是：程序就是文档。即程序的风格一致，具有

”最高 的可读性！ 第二：可维护性，可测试性高，开发周期短， 第三：具有高度的与程序员无关性 第四：最少限度的修改。最高限度的代码重用。

© 2010 PISX 13

现有的架构技术

其它编程语言发展，给我们留下了很多的架构技术 从 DOC/VIEW到MVC

从三层架构到多层架构 从数据库操作封装到 DMM， ORM新技术的流行： ActiveRecord,TableDataGetway

从面向对象，到设计模式。

我们要问，这些技术有用吗？帮助我们解决了什么问题？

© 2010 PISX 14

关于 MVC

MVC——用一个标准实现完全面向对象，从而实现与程序员无关性把用户界面实体和其对应的代码分开。

• 用户界面实体：即是视图 VIEW

对应界面实体的代码实体，使用事件映射，实现事件驱动模型。这个对应视图的代码即是模型Modal• 你如果会 JAVA SSH，或 VS.NET，你会发现，你只能编写这样的模块

而实现事件映射的，则是控制器 Controller。这就是人们所说的MVC。

© 2010 PISX 15

在 MVC基础上的编程规范

在MVC ——基础上的编程规范 简易的规范能够更进一步实现代码与程序员的无关性。

MVC所有模块均是面向对象模式的类。完全面向对象，则实现了第一层次的代码与程序员的无关性

在此基础上，只要规定：• 每个类都是单一职责的• 每个函数都是单一输入输出的

于是，则更加进一步保证了代码与程序员的无关性

注意：MVC可以实现完全面向对象，非面向对象，也可以做到MVC，这里不是把MVC当成目标，而是把完全面向对象作为目标。同时，成熟的MVC架构，应当是符合 IOC模式的。

© 2010 PISX 16

关于 DMM、 DDD

DMM——把纯数据操作与业务逻辑分隔成不同的输入输出单元，进一步简化代码，增强可读性，可维护性，可扩展性。

DMM是指领域模型 (Domain Modal)。 DDD则是 Domain Driven Development ，领域驱动设计

MVC实现了最早的三层结构：用户层，逻辑层，数据层。 但数据层仍包括业务逻辑与数据访问。于是人们想到了进一步分开。即有了现在的多层结构。

纯数据访问很简单，在 PHP中，你可以直接使用 ADODB。 但现在人们为什么要用 propel或者 doctrine?

因为我们确实需要 DMM， DDD

© 2010 PISX 17

DDD提供了什么？

DDD的目标，是处理系统业务逻辑。通常， DDD把业务逻辑封装为：

实体 值对象

规侧 服务

模块 聚合

工厂 资源库

本质上，将复杂的业务领域使用规范的，或遵循一种标准的编码方式来实现。其根本的目标，是可扩展，易变更，易维护。

© 2010 PISX 18

关于 ORM

ORM，抽象数据操作类上面，再增加一层更具体的公用操作代码。

数据层实现 DMM的方式，通常是通过 ORM实现的。 ORM 是指 Object Relation Mapping，即对数据库数据实现对象关系映射。

作为 ORM，这一技术最早流行是在 JAVA中， Hibernat是JAVA中用得最多的 ORM框架。通过 Struts, Spring, Hibernat 即我们常说的 JAVA的 SSH构成了 JAVA面向大型应用的框架。

PHP则是 propel与 doctrine最为有名。而 doctrine属后起之秀。

但随着 ROR冲击， ActiveRecord与 TableDataGetway架构被引入到了 PHP中，但 PHP仍是相对落后。

比如， RUBY中，现在有更先进的 DrySql,这在 PHP中至今仍没有。

© 2010 PISX 19

为什么要 ORM？

数据库操作，需要有大量的 CRUD。 只要有 CRUD，就需要拼装 SQL语句。 ORM把 CRUD变成通用模块，于是，业务逻辑与纯数据操作就能分开。

通过这一方式，开发中就可以省去大量的编码。

任何开发框架的最基本的目的，就是让你开发时少写编码

© 2010 PISX 20

关于设计模式

设计模式让核心代码更加松耦合。同时增加易用性与可扩展性。

例如，一些 PHP框架中提供了 APP，或 APPLICATION类。实际上它常常是一个聚合模式的类（比如使用 FACADE模式）。不仅方便使用，同时使得开发的代码规范、简单！

我们清楚：大型应用必不可少的有：Session， Logger， ErrorHandle， it18n， Validator， Filter

一些框架中就是用相关模式，将其聚合到了 APP之中。为用户开发提供了极大的方便。

© 2010 PISX 21

——框架 要还是不要？

不仅需要框架，而且要的是好框架。证据： JAVA有 SSH +（ JSF 、 Tapestry)

vs.net就是框架模式，（ VC最早的MFC就是框架） RUBY的成功，就是 ROR框架的成功

对于程序员： ——你说了不算 编程规范太多，他不执行的！ ——程序说了算 所有程序，他都是要调通的！

• 框架比编程规范还要有效！！

结论： 架构管理，如果能借助一个好的框架，则相当方便。

但是： PHP框架选用，则是相当困难的一件事情

© 2010 PISX 22

PHP架构管理中框架的使用

三种方式： 选用一个 PHP框架

• 目前没有真正支持 VIEW的框架• SMARTY不是标准的 VIEW。（ STRUTS也不是）

– FLEX > .net > tapestry > JSF > struts > smarty

• 标准的 VIEW应当如同 VS.NET(用过的人一定忘不了它的WEBFOM，WEBTABLE）

DIY一个适合自己的框架• 很多 PHP开源的软件都这样做，如 SUGAR CRM。• 因为， ZEND不可选， sysmfony也不定完全适用于企业级开发。 PHP还有什么？

• 但 DIY的结果，仍没有我们想要的 VIEW。 自己写一个框架

• 这是被指责为最不明智的。• 但如果真的写了，那可是自己享用的最方便的方式。

© 2010 PISX 23

关于 VIEW

VIEW应当是什么样子？ PHP的悲剧： SMARTY照抄 STRUTS， Prado照抄 Tapestry， log4php照抄 log4j……

ActionScript的 Flex的成功：照抄 vs.net• 结论：开源的未必都是最领先的！• 有时，有大公司投入财力研发后得出的结论，要比开源开发者拍脑袋想出来或抄出来的更具有参考价值。

真正的 VIEW是界面部件化，从而实现整个软件使用方式与界面风格的一致性。这是软件易用性的基本保证！

© 2010 PISX 24

为什么从 PHP要转向 RUBY

JSP要编译。并且是强类型的。 PHP是非强类型无需编译就能运行的语言。 同时它是开源的。 语言本身的简易性是吸引用户的根本。

早期 JSP开发人从 JAVA走向了 PHP

但开发者需要的是面对大型应用。 ROR为架构师的架构管理提供了方便。

PHP现状： 面对大型应用，你只能有以下三种选择：

• ——降低对框架的要求 选用，或 DIY，或自己写• 等待合适的框架出现（不太现实）• 而今 PHP开发人则转向 RUBY

© 2010 PISX 25

你是否会选择框架了？

PHP的MVC中没有真正易于架构管理的 VIEW。如果这一目标放宽。我们可选的也是相当的少： symfony, prado, yii

如果是小型应用，有人使用 codeigniter + log4php + htmlpurifer 再加其它应用需要的第三方开源

，也是一个好办法。 codeigniter 最差的就是它的 logger了。

官方框架： Zend Framework，请谨慎选用！

——敏捷开发模式 需要敏捷开发框架的支持！

© 2010 PISX 26

软件架构管理的具体目标

可靠性（ Reliable）。软件系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常可靠。

安全性（ Secure）。软件系统所承担的交易的商业价值极高，系统的安全性非常重要。

可升级（ Scalable）。软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。只有这样，才能适应用户的市场扩展得可能性。

可定制化（ Customizable）。同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。。

© 2010 PISX 27

软件架构管理的具体目标

可扩展性（ Extensible）。在新技术出现的时候，一个软件系统应当允许导入新技术，从而对现有系统进行功能和性能的扩展。

可维护性（Maintainable）。软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映到现有系统中去。一个易于维护的系统可以有效地降低技术支持的花费。

客户体验（ Customer Experience）。软件系统必须易于使用。这与部件化 VIEW是分不开的。

市场时机（ Time to Market）。软件用户要面临同业竞争，软件提供商也要面临同业竞争。以最快的速度争夺市场先机非常重要。只有好的框架才能提供最快速的开发！

© 2010 PISX 28

软件基本架构设计的一些原则

基本原则 ——分层 MVC+DMM 多层结构（与框架有关） ——重用 代码类库（与框架有关） ——顺序 先界面，后数据库，最后编码（MVC才能做到） ——测试 日志管理（与框架有关），代码错误管理。版本管理。

团队原则 ——编码规范 限制程序员偏好 ——项目词典 集中管理各类命名 ——独立编码 要求按标准编码 ——集中规范 以规范检查与验证

© 2010 PISX 29

好的架构应当是什么样子

用户界面（视图 view）部件化，实现界面风格与使用方式的一致性。

除用户界面（视图 view）和入口文件之外，全部面向对象 程序员能够实现 AOP——面向切面编程 采用设计模式实现松耦合，可扩展。符合 SOLID原则。 所有的类是单一职责的，所有的函数是单一功能的。并且尽可能是单一输入输出处理模式的。

所有命名：类、函数、常量、变量有《项目词典》为参照的标准进行规范。

安全：输入验证，防 XSS，防 SQL注入。错误与日志管理。

一句话：实现与程序员无关性，同时实现架构管理目标。

© 2010 PISX 30

只有架构管理也能管好项目

不一定要敏捷。 PDCAR也行！• plan计划， do it 立即实施， check it 实施中检验， action again吸取教训后再次行动 , record 继续备案供以后借鉴

项目管理的关键： ——风险控制 设计阶段：对架构与技术风险的评估 ——质量控制 良好的架构管理，保证编码质量 ——进度控制 与程序员无关性的规范编码，工作量可知，进度可控。

结论：不是不要敏捷，而是说：架构管理不可少！敏捷开发——模式 需要敏捷开发框架以及架构管理的支持！

© 2010 PISX 31

总结

ABD， AOP MVC——IOC

• module– calss

– event map or notation(action)

• view– componnent-based

• control

DMM， DDD• Domain Driven Development

– Domain modal 、 busness modal» entity

» value object

» factory

» specification mode

» resource

» service» aggregation

» module

ORM• Active Record

• Table Data Getway

• DrySql

Libraries• database & other

澎湃进取，睿智从容！

Contact information:Hot Line: 400-620-9980Website: www.pisx.com