UML sequence图中类的责任设计的疑问

在当前可以说UML已经很使用了,但是最近在做投票系统模型设计的时候,有点疑问。按照DDD设计模型是:Vote(voteId , voteTitle,totalNum)和
VoteItem(voteItemId,voteItemName,voteNum,voteId)
使用Struts+Hibernate做:疑问:
就是在设计VoteItem类(vo类)的时候,我觉得该类应该有投票数量增加的责任,所以应该把该方法作为该类的成员(我觉得)。
public void increaseVotenum()
{
int num = getVotenum().intValue() + 1;
setVotenum( Integer.valueOf( num ) );
}
问题出来了,模型类中出现了业务逻辑,而我的service包中的ServiceFactory类来得到service的单一实例。serviceImpl包中是服务的实现类。然后在服务实现类中写具体的业务逻辑,这应该才是正常的。所以increaseVotenum()方法应该写在服务实现类中。

另外我还有一个附带的疑问是:
在我的服务实现类中仍然使用了DAO设计模式,为了达到真正的解耦还定义了DAO接口和DAO的实现类(在这里我且不详细说DAO实现类的功能)DAO实现类的总体功能就是对数据库进行CRUD的基本操作和一些其他的我认为与数据库相关的功能(分页的方法),我有觉得这些方法也应该算在业务逻辑中吧!就是说我想把DAO中的内容转移到service(业务逻辑中来实现)中引入DAO是多余的吗 ?
我想问的是在JAVA WEB软件架构中DAO 与service同时存在是合理的吗》?
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值