ikan项目启动了

最近公司启动了一个电子杂志网站设计，已经初步拿到需求。
分2个功能模块，
1。电子杂志发布与展示系统。
2。杂志在线定购，购买系统。
项目组三人，
一个同事负责杂志发布，
一个同事复杂用户管理，
我复杂预定以及销售。


项目设计的内容有，权限管理，结构组成。这些都是现成的。呵呵。
接下来主要是业务上的实现。


首先马虎看了下商城的结构：发觉最主要的是功能模块是：
产品发布，
订单管理&配送，
折扣系统。

其中前两个接触过，
第三个没搞过，不知如何实现方便，看网上的朋友曾经有过此类讨论。说采用规则引擎什么之类的。模模糊糊。哈。


写在这里不知道会不会给老板骂呢？
   

评论

14 楼 wuhua 2006-11-07  

这几天再搞页面跟后台订单数据显示.搞了这么多天终于块搞定了.
这几天也不断复习以前的知识.发觉设计这东西,久了没做.就什么都忘记了

13 楼 wuhua 2006-10-30  

今天设计好了，表格，并准备写入测试数据的时候出现了
object references an unsaved transient instance错误。好久没搞web开放了，把以前的知识都丢掉了。后来去baidu找了下，发现这里的网络早有详细讨论

http://www.iteye.com/post/94837

所以简单的总结下：
1。是保存的级联对象Id为空
2。是配置问题，cascade="all". 如果级联不是all操作的话，而对方又要保存相关的对方则会出现这样的问题

12 楼 wuhua 2006-10-27  

我是个落伍的程序员。昨天见到一个很得意的冒泡显示。所以就抄了人家，给自己的项目添加的风采，呵呵
最近也想学习ajax，觉得那种交换方式真是太美妙了

11 楼 wuhua 2006-10-26  

现在总结下记录的三种方式
1，继承关系。
建立一个父类表
记录
Id   createTime  modifyTime , createUser, modifyUser

子表
..........

这样的父子的表机构奖是一个典型的树结构
这样记录的优点是，对修改，添加属性比较容易，
缺点是父类表的数据将随着子表的增加程数量级的增加

2.继承关系的另一种表述方式
在表结构上不表树结构，而是没个表都记录相关的属性，只是
在ORM上采用继承关系来设计
优点是数量不会随者表结构而数量级增加，但如果要修改属性，则比较困难

3。需要记录修改痕迹的记录。
必然订单的操作，
用户需要记录订单的流程，比如谁审核订单，谁收钱，已经发货等状态的记录。以上的方式则不适合。
这样就需要设计一个表，
这个方式就是典型的1：n的关系

10 楼 wuhua 2006-10-25  

dengyin2000 写道

wuhua 写道

今天浏览了一个老贴关于每个表的相关记录（必然，创建时间，修改时间，创建者，修改者，）因为这些记录是固定的，有很多表都用到。所以我把它抽取出来，另建一个表Record
然后在需要用的这个表内容的时候，只需要引入Record，并创建get/set就行，
而我同事则是创建一个BaseObject，然后通过继承它来实现上面的功能，不过它的缺点是，必须每个表都需要记录Record的字段，觉得给表造成臃肿的感觉

感觉继承好点， 我们项目中有这样做得，把 id, createTime, lastUpdateTime 放到BaseDomain里面

你这样做就还不错。
但有些表格它要求记录创建者，修改者是谁，有些表则不比要这么做。如果采用继续的话，如果另外客户要求为这个表格再加些描述的话，则不是要去修改很多表格，如果采用是关联的话，则修改一个就ok了。

9 楼 dengyin2000 2006-10-25  

wuhua 写道

今天浏览了一个老贴关于每个表的相关记录（必然，创建时间，修改时间，创建者，修改者，）因为这些记录是固定的，有很多表都用到。所以我把它抽取出来，另建一个表Record
然后在需要用的这个表内容的时候，只需要引入Record，并创建get/set就行，
而我同事则是创建一个BaseObject，然后通过继承它来实现上面的功能，不过它的缺点是，必须每个表都需要记录Record的字段，觉得给表造成臃肿的感觉

感觉继承好点， 我们项目中有这样做得，把 id, createTime, lastUpdateTime 放到BaseDomain里面

8 楼 wuhua 2006-10-25  

今天浏览了一个老贴关于每个表的相关记录（必然，创建时间，修改时间，创建者，修改者，）因为这些记录是固定的，有很多表都用到。所以我把它抽取出来，另建一个表Record
然后在需要用的这个表内容的时候，只需要引入Record，并创建get/set就行，
而我同事则是创建一个BaseObject，然后通过继承它来实现上面的功能，不过它的缺点是，必须每个表都需要记录Record的字段，觉得给表造成臃肿的感觉

7 楼 wuhua 2006-10-25  

今天设计了订单的数据原型。
Order － 订单
Attr － 订单属性（记录相关的状态，时间，已经价格）
SubOrder － 订单的相关产品记录（比如一个订单可以记录多个产品），此类主要是记录Product <->SubOrder为1：1关系，然后Order<->SubOrder为1：N关系，这样就可以在查询产品的销售情况上处理比较方便。

6 楼 wuhua 2006-10-25  

根据最初步的需求，公司要求的折扣是，用户如果订阅半年以上的杂志，则可以获取相应的折扣，必然送礼品，或者免费获取其他杂志的。

5 楼 叶子 2006-10-23  

折扣看需求了.

可能是对某批次的一起折扣
买某个送某个的折扣
单独某件促销
买满几个送几个.
第N个是半价
还有折扣时间...

乱七八糟的.搞到后来我就是把折扣品作为新商品作价...=____=

4 楼 wuhua 2006-10-23  

安装了firefox2之后终于解决了，很大部分js问题，现在我可以发图片了。好开心。哈
下面是设计的一些流程图

3 楼 ouspec 2006-10-23  

wuhua 写道

发表评论可否也设计成可上传文件或者图片的功能
我想上传几张设计流程都不可以好是郁闷

发表评论也可以上传文件，不过要在论坛里面帖子下面点击发表回复，下面有新增附件，可以上传图片或者文件

2 楼 wuhua 2006-10-23  

产品发放跟杂志发布处同一平台，顾，我不用理会。
所以先设计下订单管理。
这里有个问题，根据以前的经验呢。设计订单会涉及到几个问题。
1，订单与用户的关联是怎么样的（1：n）
2，订单与产品的关联是怎么样的（有两种可能1：1，1:n),这里又设计到一个问题，是一张订单对应一个产品呢。还是一张订单对应N个产品，如果是1：1的话，则在查询，价格统计已经帐单分析方面比较有优势，当对用户来说确是劣势，因为，没个产品对应一个单，那订单将随着购买的数据儿直线上身。这样用户会不会很晕呢。1：n关系将可以很好的处理这些问题。但对于后台处理将会造成麻烦。
3，订单与其他附属订单的关系（比如折扣，赠送等）

1 楼 wuhua 2006-10-23  

发表评论可否也设计成可上传文件或者图片的功能
我想上传几张设计流程都不可以好是郁闷