|
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2007-04-20
robbin讲得非常不错，解决了我以前得不少疑问。
非常幸运，拿同事的名片该了一下名，抽奖到一本书。 |
| 返回顶楼 | |
|
发表时间：2007-04-20
Gavin King的演讲真的没有听得太懂，我英文太差:(，不过Gavin King对于ROR的反映之激烈，挺有意思的。
Robbin对Hibernate的总结，大部分比较认同，不过对于数据库的粒度设计，我觉得倒不是绝对的，Hibernate在处理复杂业务的数据结构上还是有些力不从心，具体情况具体对待吧，这和世界上没有万能药水。 对于晓刚的Seam介绍，比较简单，Seam到底怎么样，还需要实践来检验啊。 |
| 返回顶楼 | |
|
发表时间：2007-04-20
Readonly 写道 Robbin 写道 双向关联，inverse=“true”的情况下应避免使用集合缓存 这个是因为你的这个实践建议造成的： Robbin 写道 在分层结构中通过DAO接口用session直接持久化对象，避免通过关联关系进行可达性持久化 这样就会带来内存模型和数据库模型不一致的情况 偶的实践建议是相反的：通过关联关系进行可达性持久化 在Parent上有这种方法：
add(Child child) {
child.setParent(this);
children.add(child);
}
remove(Child child) {
child.setParent(null);
children.remove(child);
}
设置inverse = true 和 cascade = all-delete-orphan 删除某个child的操作就变成一句话搞定： parent.remove(child) 这样内存和数据库保持完美一致，而且代码写起来也简单，不需要ChildDAO上有啥create/delete/update/ Child的方法 双向关联的2级缓存也是非常好用的 这个问题要讨论下去是没有底的。 Readonly的做法是我采用的做法，这在多数情况下都不会存在问题。有的人会担心所谓的效率问题，老实说，除非Children这边成千上万，否则根本不会造成什么效率问题。 不过也有的时候，这种做法很难施展拳脚。比如说，有很多典型的业务系统，它不允许有物理删除这个概念，必须打上disabled标志表示删除。那么这个时候，这个双向的关联就显得很苍白无力，我在这种情况下，除了使用robbin的这个思路，还没有想到有什么很好的解决方法。 |
| 返回顶楼 | |
|
发表时间：2007-04-20
不知道为啥Gavin King会热衷于JSF这种基于事件驱动的Web层框架，实在是不能理解。
最近在用JSF＋Spring webflow做项目，那叫一个痛苦。不仅说它的编程模型特别诡异，让我们这种熟悉了传统MVC概念的程序员无法接受，最要命的是它特别喜欢用Tag，做出来的页面是不能View的，这是最最无法交流的地方了。按照robbin的说法，直接对这个东西判了死刑。 |
| 返回顶楼 | |
|
发表时间：2007-04-20
nihongye 写道 引用 eager-fetch 我这边根本实现不了，在many-to-one端 配不配fetch="join"
视情况而定啦。建议开新贴讨论这个问题。我理解的eager-fetch保证的是not lazy（这一定必须保证）.而join是一种期望的抓取策略，并不一定能保证。 开帖了：http://www.iteye.com/topic/72783 |
| 返回顶楼 | |
|
发表时间：2007-04-20
什么时候能够放出Gavin King演讲的音频来听听，当然Robbin的也是很欢迎的。到的只有100来人，不代表想去的就那100来人啊！照顾照顾我们这些没去的吧。
|
| 返回顶楼 | |
|
发表时间：2007-04-20
事件驱动是进步还是倒退？我认为还是进步的，起码在编程思想和模型是进步的。web开发的复杂度有request-response模型过于简单的原因在其中，为了实现丰富的业务必须从简单处构建，做了不少工作。jboss seam的着力点在于企业开发，所以在栈中加入了与jboss诸多组件的粘合元素，当然其中有商业元素，但选择权在你手中，如果商业开发采用seam方案，我认为整体优势还是非常不错。jsf行还是不行，先别忙下结论，有时候说话太多会忘记做事，行与不行不是说出来的。呵呵。
|
| 返回顶楼 | |
|
发表时间：2007-04-20
Gavin King昨天似乎不在状态，如果没有轻微脑震荡可能气氛更热烈，另外在场的部分人英文能力可能都不怎么样（包括我在内），互动性差是这类技术讲座的通病，尤其是老外的场次，否则Gavin老兄会有更多激情来秀出风采。
|
| 返回顶楼 | |
|
发表时间：2007-04-20
去听了一下，收获还是很多的。最可惜的是，没有中奖啊。。。
|
| 返回顶楼 | |
|
发表时间：2007-04-20
downpour 写道 不过也有的时候，这种做法很难施展拳脚。比如说，有很多典型的业务系统，它不允许有物理删除这个概念，必须打上disabled标志表示删除。那么这个时候，这个双向的关联就显得很苍白无力，我在这种情况下，除了使用robbin的这个思路，还没有想到有什么很好的解决方法。 我认为，这种情况，并不适合做简单的父子关系，即子表有父表ID做外键，因为就业务逻辑而言，“删除”并不是父亲杀死儿子，而是父亲暂时不认这个儿子。我倾向于做3张表，父亲们，儿子们，父亲儿子关系表。父亲表和父亲儿子关系表应该会适合Robbin的思路。 |
| 返回顶楼 | |
