使用Struts2+Spring+Hibernate+sitemesh做的一个在线音乐站点

前段时间用用Struts2+Spring+Hibernate+sitemesh做的一个在线音乐站点写的一个在线音乐
的站点.功能实现的相对比较粗糙(如歌曲列表没考虑分页什么的),另外只能使用IE(使用了ActiveX
控件播放音乐的).刚学的struts2,主要是想练一下.

评论

45 楼 tiyi 2008-03-16  

俺到现在还没搞清楚用sitemesh的好处是什么……

44 楼 asheng88 2008-03-16  

我指的线程问题是单例模式下访问器的同步问题，有同步synchronized就有可能死锁，如果没有synchronized，那么假想两个线程调用访问器，而其中一个线程在new之前睡眠，醒来的时候第二个线程已经new完成而第一个线程不知道，怎么样？这是单例吗？更恐怖的是表现的线程频繁！

43 楼 fuliang 2008-03-16  

asheng88 写道

fuliang 写道

action是线程不安全的,需要每次请求创建一个action

spring管理的bean不都是单例的吗？也许表现层的action例外!
业务bean呢？service和dao都是单例的吧，是什么保证单例线程安全？

Spring管理的bean可以配置成singleton和prototype的,
一般DAO和Service都应该是单例的,Struts2的Action模型本身就不是单例的,因为
通常Action是有数据成员,并且通过getter,setter与页面的字段绑定.
service和dao事实上他们通常没有可变的东西,Service只依赖于dao,dao只有CRUD操作,
本身就是线程安全.当然你也可以使用一些共享的可变变量,把他们搞成线程不安全的,然后配置成
原型模式的,当然这会影响一点效率.

42 楼 asheng88 2008-03-16  

fuliang 写道

action是线程不安全的,需要每次请求创建一个action

spring管理的bean不都是单例的吗？也许表现层的action例外!
业务bean呢？service和dao都是单例的吧，是什么保证单例线程安全？

41 楼 fuliang 2008-03-16  

asheng88 写道

fuliang 写道

前段时间用用Struts2+Spring+Hibernate+sitemesh做的一个在线音乐站点写的一个在线音乐
的站点.功能实现的相对比较粗糙(如歌曲列表没考虑分页什么的),另外只能使用IE(使用了ActiveX
控件播放音乐的).刚学的struts2,主要是想练一下.

表现层的action也可以注射到spring容器？

Action可以由Spring容器来管理,Service可以直接注入到Action中,但需action配成prototype的,因为struts2,action是线程不安全的,需要每次请求创建一个action

40 楼 asheng88 2008-03-16  

fuliang 写道

前段时间用用Struts2+Spring+Hibernate+sitemesh做的一个在线音乐站点写的一个在线音乐
的站点.功能实现的相对比较粗糙(如歌曲列表没考虑分页什么的),另外只能使用IE(使用了ActiveX
控件播放音乐的).刚学的struts2,主要是想练一下.

表现层的action也可以注射到spring容器？

39 楼 manmoon 2008-03-13  

这么多jar库，累不累，有没有烦的感觉？
做一个网站没必要把spring+hibernate+....都用上，
感觉有点像电影里那个台词：
用就用最好的，你还甭嫌贵。。。。。。

38 楼 ardenliu 2008-02-27  

没有看到认证的部分，不知道是如何处理的啊。

37 楼 fuliang 2008-02-26  

fhjxp 写道

fuliang 写道

fhjxp 写道

看了一下源码，问一下，dao，service定义每个都定一个接口有什么用啊？有什么好处？

基于接口而不是类编程，这样Service层依赖于dao层的接口而不是实现，可以方便的替换dao的实现。基于接口
编程提供了可插拔的松耦合的编程方式。Spring倡导基于接口编程的方式，这是一种良好的编程习惯，在Spring中使
用接口是自然的，被鼓励的。

你的回答里面我只看到一个理由：方便替换实现。为什么要松耦合、面向接口、好习惯还是为了这个。

真的方便了么？
1,首先说90%以上的项目，都不存在另外作多套Dao，Service需要进行切换，我接触过到的项目（开发时间近三年）都没有遇到过这个情况，偏偏每个项目都要搞了接口，不管开发还是维护都没有得到什么好处。

2,如果某个service方法要修改具体实现，不管有接口还是没有接口都需要同样的修改代码。如果还需要修改方法的名称或参数，同时还得修改接口类，得改两处，反而麻烦了。

1、我曾经参加过一个项目，原来使用Hibernate,从这个项目派生出一个项目要用JPA,有了DAO接口就可以方便替换了，否则，你在每个Service中找使用的HibernateDAO,然后改成现在的JPA实现的DAO，这是一个烦琐而易出错的事情，这就是依赖于具体实现的害处。
　　接口作为一种契约，其他使用你代码的人只需要知道你接口中提供的方法，就可以使用你的代码了，而接口通常是方法的最小子集（要暴露给用户使用的部分）。如果你只有实现类，往往会让使用你代码的人陷于细节，自己查找你到底暴露那些方法给我用。维护方面，如果你的实现需要很大改动的时候，有了接口别人在修改你代码的时候，就会知道我只要实现了你定义的接口的功能就ok了，其他的细节和我无关。
２、你所说的得改两处，是因为接口没有定义好，改动两处当然是不可避免的。如果你没有接口，别人要修改的话，他都不知道他的改动对其他部分的影响有多大，因为他很可能不知道，你要暴露什么，其他部分依赖于哪些方法。
３、基于实现类违反了面向对象的设计原则：OCP、LSP、DIP

36 楼 fhjxp 2008-02-26  

fuliang 写道

fhjxp 写道

看了一下源码，问一下，dao，service定义每个都定一个接口有什么用啊？有什么好处？

基于接口而不是类编程，这样Service层依赖于dao层的接口而不是实现，可以方便的替换dao的实现。基于接口
编程提供了可插拔的松耦合的编程方式。Spring倡导基于接口编程的方式，这是一种良好的编程习惯，在Spring中使
用接口是自然的，被鼓励的。

你的回答里面我只看到一个理由：方便替换实现。为什么要松耦合、面向接口、好习惯还是为了这个。

真的方便了么？
1,首先说90%以上的项目，都不存在另外作多套Dao，Service需要进行切换，我接触过到的项目（开发时间近三年）都没有遇到过这个情况，偏偏每个项目都要搞了接口，不管开发还是维护都没有得到什么好处。

2,如果某个service方法要修改具体实现，不管有接口还是没有接口都需要同样的修改代码。如果还需要修改方法的名称或参数，同时还得修改接口类，得改两处，反而麻烦了。

35 楼 fuliang 2008-02-26  

fhjxp 写道

看了一下源码，问一下，dao，service定义每个都定一个接口有什么用啊？有什么好处？

基于接口而不是类编程，这样Service层依赖于dao层的接口而不是实现，可以方便的替换dao的实现。基于接口
编程提供了可插拔的松耦合的编程方式。Spring倡导基于接口编程的方式，这是一种良好的编程习惯，在Spring中使
用接口是自然的，被鼓励的。

34 楼 fhjxp 2008-02-26  

看了一下源码，问一下，dao，service定义每个都定一个接口有什么用啊？有什么好处？

33 楼 fhjxp 2008-02-26  

xly_971223 写道

着重看了一下service 在这种简单应用中dao层完全可以去掉
写一个功能全点的dao就可以 大大提高了开发效率

确实应该这样做，我也正做一个类似项目就是这样高，Action，Service，自己封装一个Dao

32 楼 梦秋雨 2008-02-23  

fuliang 写道

lovelyivy1982 写道

郁闷！怎么不附包阿？找得好辛苦

包太多,附件放不下,不好意思...

用Maven管理依赖，发东西的时候就可以不用管jar了。给个POM.xml就OK

31 楼 wangjian3q 2008-02-22  

<%@ taglib prefix="s" uri="/struts-tags" %>

为什么  s 标签是错误的 呢

30 楼 duronshi 2008-01-07  

能否将那些包也一起放上来呀?照顾下新手
谢谢

29 楼 luckne 2008-01-07  

我们也做了一个类似的项目，但是不知道为什么运行的时候 tomcat 吃类存很厉害，到后面整个application 会变慢，我用工具看了看好像是struts2没有做回收。。。不知道有没有遇见过这样的情况。。。现在我们在作压力测试想得到更确切得问题所在

不知道各位有没遇见这样得情况？

28 楼 to2 2008-01-06  

谢谢~如果有分页示范就更好了，照顾一下我这样的新手。

27 楼 fuliang 2008-01-06  

erikchang 写道

建议在一个附件中给相关包注名

readme.txt里面有

26 楼 fuliang 2008-01-03  

seasar_tei 写道

做得不错，但是小弟有一点疑问。就是歌手这个对象是不是继承体系过于复杂呢？

恩，是有点复杂。这就是面向对象的两难的局面。你的领域模型越面向对象，你与数据库，表现层就越阻抗不相容。如果仅仅从这个简单应用歌手的继承体系显得太复杂了，显得只是在找麻烦，呵呵