不知道是不是该用vo，或者说该怎么用vo

最近在实现一个微博，遇到了很多大小问题，下面是其中一个问题：

用户与用户之间可以加好友，但是好友可以是单向的，如果a将b加为好友，那么a就是b的粉丝。反过来也一样。
我在设计数据库的时候，建了个user与user的多对多关系表。

在页面上，浏览用户好友列表的时候，可以显示出该用户每个好友的粉丝数，也就是有多少人加了这个人为好友。
这个粉丝数我想是通过sql count出来的，但是User这个PO里没有这个属性。于是有个小问题：

是否该建个 vo，作为dao查询结果返回？我用的是ibatis,那么resultClass就成了这个vo了，这样做好吗？

我现在的做法，是建了个VO，ibatis的resultClass设置为vo，sql中使用子查询。

public class Friend {
	private Long userId;
	private String nickname;
	private String address;
	private Integer fans;
        //getters and setters...
}

	<!-- 查询用户所有好友,返回VO -->
	<select id="findByUserId" parameterClass="Long" resultClass="vo.Friend">
		<![CDATA[
			select
				fu.user_id as `userId`,
				fu.nickname as `nickname`,
				p.residence_id as `address`,
				(select count(*) from friend where friend_id=fu.user_id) as `fans`
			from
				friend as f
				inner join user as fu on fu.user_id=f.friend_id
				left join profile as p on p.user_id=f.friend_id
			where
				f.user_id=#value#
		]]>
	</select>

本人还是个小菜鸟，java工作才1年出头，请大侠们多指点，万分感激！

你这个帖子估计很快就要被JE和谐掉。

回答问题，我也是新手，但是我面对这种情况，毫不犹豫，给你所谓的po增加个count属性。
要不你就返回一个hashmap（不推荐）。

每个登录到自己首页的人,他的好友数都是count出来的? 这样不太好吧.你们预计的规模能有多少?有没有评估过这个查询的数量级?毕竟这个数据会常显示,至少一次登陆就给查一下.是不是可以考虑冗余一下这个字段?

问题很菜，见笑了！
你的意思是说在用户表中加入一个字段(例如叫count)来标记他被多少人关注？
这样就是有人在关注他的时候update一下这个用户的这个字段，有人解除关注的时候也update一下这个用户的这个字段。

不知我这么理解对吗？

非常感谢，我没有过成熟项目的经验，呵呵，确实应该冗余一下。

太耗数据库资源了

你的user不是多对多的吗？
那么user里面应该有个List<User> fans来保存用户.
然后fans.size()就知道个数了..

ibatis的result不要和VO混成一谈，ＶＯ是面对页面展示层，如果ibatis的result就直接返回的是Vo,那么项目就很难扯清了。。

相比起显示count的次数来讲,我想关注和取消关注的次数应该是少好几个数量级的.
比如说,这个产品在1个月能有1万个用户,平均每个用户关注50人(这个平均关注度已经很高了吧).那么在这一个月中,需要50万次update操作.假如仅在登录首页的时候要显示count(这应该非常少了吧?事实上可能会很多地方都显示).按每个人每天进入首页1.5次.那么也给查询45万次.(要注意的是,当用户很多的时候,这个查询的系统消耗非常恐怖).
最重要的是,当你去关注某人的时候,你还会看到对方的count的.所以每一次的update都意味着至少两次的查询(查询对方,和刷新后显示自己的,这还不包括大家串门时到别人首页时看到的别人的count).


所以说,count的query和count的update次数差一百倍绝对不为过.

我还是建议冗余count这个字段.只要注意update的时候行锁定而不是表锁定就行.

至于为什么不去用应用缓存,而是要采用数据库字段冗余,这是因为count只是一个字段.应用级别的缓存,最好还是缓存一个业务单元.count有点过小了.比如说,经过分析,你发现这个服务中,30-50% %的请求都只是针对5%的用户的信息进行请求的,此时你就需要去缓存这5%的用户的完整信息.而不是很广义的去缓存100%的用户的某个信息.

你不能只是为查个总数,就要把每个数据都取出来吧....

而且说实话,像围脖这样的应用,交叉数据及其多,我觉得还是纯jdbc来的好.任何orm工具最后都是瓶颈.