|
锁定老帖子 主题：SSH架构中的Struts似乎很鸡肋
该帖已经被评为新手帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-05-26
icewubin 写道 抛出异常的爱 写道 由于多线程关系所以尽量不要使用状态属性.....否则要七锁八锁的....很是麻烦.
在2中没这个问题吧，action属性的生命周期是一个request。 2也没有actionform这东西吧 |
| 返回顶楼 | |
|
发表时间：2009-05-26
最后修改：2009-05-26
关于鸡肋的问题大家就到此为止吧，呵呵！
鸡肋的其实不是struts，我们自己要检讨！
参见下一帖 鸡肋问题解决之道！欢迎大家接着仍鸡蛋！
|
| 返回顶楼 | |
|
发表时间：2009-05-26
最后修改：2009-05-26
抛出异常的爱 写道 icewubin 写道 抛出异常的爱 写道 由于多线程关系所以尽量不要使用状态属性.....否则要七锁八锁的....很是麻烦.
在2中没这个问题吧，action属性的生命周期是一个request。 2也没有actionform这东西吧 只要属性生命周期多线程没问题，自己定义或者是直接利用POJO，用反射封装一下也不麻烦吧。 有可能我们说的不是一件事，当我没说好了。 |
| 返回顶楼 | |
|
发表时间：2009-05-26
不知所云.
|
| 返回顶楼 | |
|
发表时间：2009-05-26
jcs7575 写道 我认为action不就是做转发来用的
如果不用form那表单的数据传不过来啊 如果不用struts 如果用velocity也是一样需要有spring的controller 也需要有model的 你觉得呢？ 为什么不用form表单数据传递不过来呢？ request.getAttribute()不是一样取么！！ |
| 返回顶楼 | |
|
发表时间：2009-05-26
betafox 写道
sslaowan 写道
关于ActionForm，参见DTO模式，如果你的业务层实现为一个Rich Domain Model，那么DTO就很有用了
关于Action，参见Command模式，关于Struts核心的架构可参见《J2EE核心模式》 这个话题没什么好讨论的，如果你理解Struts的设计思想，那么你就会认为你这么使用，是正确的~~ 理论上是正确的，确实如君所言没什么好说的，我也认为架构上应该遵循这样的层次，然则，理论化的东西在实战中往往不是效率最优的，相信这点大家都有体会，所以我才有此问。
|
| 返回顶楼 | |
|
发表时间：2009-05-26
sslaowan 写道
betafox 写道
sslaowan 写道
关于ActionForm，参见DTO模式，如果你的业务层实现为一个Rich Domain Model，那么DTO就很有用了
关于Action，参见Command模式，关于Struts核心的架构可参见《J2EE核心模式》 这个话题没什么好讨论的，如果你理解Struts的设计思想，那么你就会认为你这么使用，是正确的~~ 理论上是正确的，确实如君所言没什么好说的，我也认为架构上应该遵循这样的层次，然则，理论化的东西在实战中往往不是效率最优的，相信这点大家都有体会，所以我才有此问。
看了我们应该怎样看待框架。写的很好很清晰，谨受教！ |
| 返回顶楼 | |
|
发表时间：2009-05-26
呵呵，有同感，
|
| 返回顶楼 | |
|
发表时间：2009-05-26
直接用struts 2
|
| 返回顶楼 | |
|
发表时间：2009-05-26
我觉得楼主的见解有以下问题：
1） 对DTO(数据传输模型)，Domain model(领域模型)，数据实体(Entity)之间的理解有些问题 2） 不同层拥有不同的职责，如果不分层，楼主完全可以在JSP页面中完成所有的事情。 3） Action其实就是做一些数据校验，将逻辑计算推到服务层 4） 数据的展示和数据的计算模型很多情况下不区分，但是不能说本质上没有区别，也有很多时候计算模型和展示模型不一致。 请参考 |
| 返回顶楼 | |
