初学Duwamish7.0笔记

王朝other·作者佚名  2006-01-08
窄屏简体版  字體: |||超大  

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

BusinessFacade和BusinessRule应用了设计模式中facade模式,具体信息参见<<设计模式>>一书,这个模块基本上是按照用户的需求来设计操作;

SystemFramework:这个可以对于我们开发电子商务工程做一个很好的借鉴,目前它只完成了application的若干设定;

Common:定义了系统的数据库结构,采用了最普遍的数据库到对象的映射关系(我还没有细看)

,这是最普通的一种结构;

DataAccess:定义了访问数据库的操作,也是按照表格分类的,也很普通(不要以为普通不好啊,通用的东西简单但是最可靠),和Common分开主要是降低了耦合度;

Web:应该就是UI吧,呵呵,这个,我不是很在行

这是一个经典的电子商务架构,不过我有一点想法,从软件设计的角度考虑:

电子商务工程的开发,最重要的是什么?我也不知道,是不是在面对客户千奇百怪的需求时,系统的架构可以应付自如?

那么当客户提出一个新的需求时,会有几种情况呢?

这个需求涉及的东东在数据库上已经有现成的数据结构了,并且BusinessRule上也提供了相应的功能,那么,只需要增加BusinessFacade了,那么,可否增加一个BusinessFacadeManager模块,可以成为SystemFramework或者BusinessFacade的子模块,对BusinessFacade实行动态加载,这样,同一个application针对不同客户的操作需求,可以灵活加载多种BusinessFacade策略;

这个需求涉及的东东在数据库上已经有现成的数据结构了,但是BusinessRule上没有相应的功能,那么显然,需要增加BusinessRule和BusinessFacade了,所以,再看1,不如增加一个BusinessManager,动态管理BusinessRule和BusinessFacade;

这个需求涉及的东东在数据库上已经有现成的数据结构了,但是BusinessRule上没有相应的功能,并且,DataAccess这一层上也没有定义相应的操作,那么很显然,就需要Update DataAccess了;

同理,如果数据库中也没有新的需求需要的数据结构,则需要重新设计数据库结构.

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

数据库的设计,有很多中方法,Duwamish的这个例子是最普通的一种,<<程序员>>上好像有一篇文章,介绍了很多种把关系型数据库转化成对象模型的方法,记不清了

;BusinessRule的设计,除了充分做好需求设计以外,需要多看看OO,设计模式之类的书籍,尽量增加系统的灵活性(好像是废话,因为这是最理想的状态了),但也要避免"过分设计";BusinessFacade也一样,一定要做好文档工作,否则,随着用户需求的增多,facade中的操作越来越多,你能保证一定每个你都记得吗?:)

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
 
 
© 2005- 王朝網路 版權所有 導航