现在的位置: 首页 > 综合 > 正文

循证架构–寻找最适合自己的架构

2012年09月30日 ⁄ 综合 ⁄ 共 2809字 ⁄ 字号 评论关闭

没有最好的架构,只有最合适的架构。循证架构是《Expert One-on-One J2EE Development without EJB》一书中推崇的架构思路,用俺们的话说就是摸着石头过河,找最适合自己的架构。

俺现在soho,大活不多,小活不断。我的工作具备以下特点:

(1) 根本没摸清楚需求的时间。需求都是从原型到Demo到版本1到版本2探索出来的。经常需求变化非常大,因此,必须以敏捷方法为基础;

(2) 一般没多少数据需要存储,顶多百万级;

(3) 需要极度的压榨开发效率。一个工作,10天完成和20天完成,那收益前者就是后者的两倍。

在上面(1)-(3)驱动下,俺摸索出的架构见下图:

myarch

从下往上,简单说说:

(1) 数据库:db4o。谁用谁知道,哈哈,爽。什么ORM,SQL,DataSet,统统是过眼云烟了。一切都是普通对象。数据库几乎是0设计。数据接入也非常非常的简单。

(2) Db4o之上得有一个逻辑层,来应付需求变化。这一层主要就是各种实体对象,需要良好的设计,否则,应付不了需求的变化。这一块我一般要设计比较完备的event体系,便于后期修改与组合。

(3) 服务层:主要是RIA应用需要。如果是Winform程序,不用这一层。

(4) UI逻辑层:最开始没弄这一层,最后鉴于在界面那一块太耗时间,就加了这么一层。这一层主要是:

a) 对于单个控件,将控件的常用操作逻辑封装成扩展方法;

例子: Winform程序中的Invoke方法使用起来很烦人,涉及到多个线程,还要判断多次 IsHandleCreated == true(经常忘记,导致bug)。于是,需要将它封装成扩展方法。

代码如下:

Code

 

b) 对于多个控件,使用Mediator模式,将多个控件之间的组合抽象出Mediator类,方便重用。这一点我最开始是用户控件方式进行封装,结果发现太不灵活,最后改用Mediator,再配合扩展方法,开发速度biubiubiu的就上去了。

(5) UI:Html是万恶之源,能不用就不用。可以选择的话,我主要用Winform, Flex,SL作为前端。纯Web开发是不碰了(市面上做Web开发的太多,不趟这个混水了)。

以上架构,视项目而定。如果项目的数据部分比较关键,我现在还是保守的在用关系数据库。虽然db4o已经那么多年了,还是得保守一点用。

如果能完全按上面五点去做,那开发简直和在空中飞翔一样爽。

btw. 如果一切都OO起来,写程序真是享受,象写诗一样……

 

抱歉!评论已关闭.