初学Duwamish7.0笔记

没有做过电子商务,胡乱说上几句:

1. BusinessFacade和BusinessRule应用了设计模式中facade模式,具体信息参见<<设计模式>>一书,这个模块基本上是按照用户的需求来设计操作;
2. SystemFramework:这个可以对于我们开发电子商务工程做一个很好的借鉴,目前它只完成了application的若干设定;
3. Common:定义了系统的数据库结构,采用了最普遍的数据库到对象的映射关系(我还没有细看),这是最普通的一种结构;
4. DataAccess:定义了访问数据库的操作,也是按照表格分类的,也很普通(不要以为普通不好啊,通用的东西简单但是最可靠),和Common分开主要是降低了耦合度;
5. Web:应该就是UI吧,呵呵,这个,我不是很在行

这是一个经典的电子商务架构,不过我有一点想法,从软件设计的角度考虑:
电子商务工程的开发,最重要的是什么?我也不知道,是不是在面对客户千奇百怪的需求时,系统的架构可以应付自如?
那么当客户提出一个新的需求时,会有几种情况呢?

1. 这个需求涉及的东东在数据库上已经有现成的数据结构了,并且BusinessRule上也提供了相应的功能,那么,只需要增加BusinessFacade了,那么,可否增加一个BusinessFacadeManager模块,可以成为SystemFramework或者BusinessFacade的子模块,对BusinessFacade实行动态加载,这样,同一个application针对不同客户的操作需求,可以灵活加载多种BusinessFacade策略;
2. 这个需求涉及的东东在数据库上已经有现成的数据结构了,但是BusinessRule上没有相应的功能,那么显然,需要增加BusinessRule和BusinessFacade了,所以,再看1,不如增加一个BusinessManager,动态管理BusinessRule和BusinessFacade;
3. 这个需求涉及的东东在数据库上已经有现成的数据结构了,但是BusinessRule上没有相应的功能,并且,DataAccess这一层上也没有定义相应的操作,那么很显然,就需要Update DataAccess了;
4. 同理,如果数据库中也没有新的需求需要的数据结构,则需要重新设计数据库结构.

一个好的电子商务设计,我想首先应该有一个好的数据库设计,这样可以避免3和4最大程度上不要出现,这是基本要求了,其次,充分搞清楚客户的需求,做到BusinessRule这一层可以尽量少的增减,再次就是BusinessFacade了,不过我想,BusinessFacade99%都是会重新改的,如果用户有新的需求的话(当然,不排除用户通过对若干个操作做不同的组合,来实现了一个新的功能,可惜用户通常只愿意按照用户手册一步一步去做).

数据库的设计,有很多中方法,Duwamish的这个例子是最普通的一种,<<程序员>>上好像有一篇文章,介绍了很多种把关系型数据库转化成对象模型的方法,记不清了;BusinessRule的设计,除了充分做好需求设计以外,需要多看看OO,设计模式之类的书籍,尽量增加系统的灵活性(好像是废话,因为这是最理想的状态了),但也要避免"过分设计";BusinessFacade也一样,一定要做好文档工作,否则,随着用户需求的增多,facade中的操作越来越多,你能保证一定每个你都记得吗?:)

本文地址：http://com.8s8s.com/it/it45930.htm