残脑帖，来说说rmxp储存后的阿尔西斯还是原来的阿尔西斯吗

yangff

Not define =


yangff于2010-12-23 21:46补充以下内容：
Not define =

连贴大侠

替换队员有一个东西叫做初始化，所以阿尔西斯还是阿尔西斯.

tamashii

不是了吧，大概……

苏小脉

chaochao  另外这种做法用不好就会异常，为什么？自己想去。楼主说的这种情况，其实完全没必要这么做。  发表于 9 小时前

chaochao  实际的项目中，几十个属性什么的复杂的结构是很常见的，你如果是因为楼主说的原因而要这么搞，那我就要佩服你的耐心或者你对机器速度的信心

请不要做这个假设，我没有针对 RM 这种在初始化时就把所有数据库数据保存到内存中的持久对象的情况（$game_* 引用的对象）。因为默认 RM 的数据库数据都是静态的，且内存中已经有一份拷贝，那自然可以只操作标识了。“实际的项目中”是不可能一次性把数据库数据都装载到内存中的，所以为了从表中获取对象及其属性，就需要让集合的元素成为对象这个类型。比如 Hibernate 的 criteria，默认就是返回一个 Collection<Object>，元素实际的类型是关系数据库映射到 Java 的对象类型。

老夫子

……高深莫测……

chaochao

回复 苏小脉 的帖子

嘛，嘛……数据库里的ID，你是不能修改的。所以才用ID来表示一个对象。而且所有的副本也都是从数据库这个唯一的地方取出的，修改也是要向数据库发送数据的。总之对数据库中数据的操作，也都是在对数据库这一个地方操作，Hibernate其实就相当于减少了程序员与数据库交互的代码，使数据库的操作看起来更像面向对象的程序。
大多数情况下，客户端的数据经过了客户端的修改，如果没有更新到数据库，通常都是无效的，数据依然以数据库读取的为准。这样的情况正好是我说的RM中必须要注意的情况。总之副本的修改是无效的。但与数据库情况不同的是RM的副本与正本是在同一个域的，所以非常容易混淆。那么我才不建议这么搞。我的意思是，不需要副本的时候，千万不要用副本。

PS:反正我只在讨论RM，要讨论其它东西，还是算了。

苏小脉

回复 chaochao 的帖子

而且所有的副本也都是从数据库这个唯一的地方取出的，修改也是要向数据库发送数据的。总之对数据库中数据的操作，也都是在对数据库这一个地方操作，Hibernate其实就相当于减少了程序员与数据库交互的代码，使数据库的操作看起来更像面向对象的程序。

实际的应用中充斥着动态数据，有时可能会希望把动态数据维持到数据库中，而对于使用  Hibernate 的人来说，规范就是建立一个 transient 的对象，之后用 Transaction#commit 使其持久。但在此之前，如果你想做个域的重复值检测（即如果表中已经有一行包含了特定的几个域的相同值就不 commit），传统的做法自然是操纵列的 UNIQUE CONSTRAINT，但如果出于某种原因你不想 ALTER 列的属性，就只能让 Hibernate 把数据 SELECT 出来，然后挨个比较映射后的对象全部属性了。默认的 Object#== 自然做不到这一点，所以让子类覆盖。

我很赞同你上面关于避免数据库对象副本的观点，普通的 RM 游戏确实完全不需要这么干。然而覆盖 Object#== 只是一个思路，可以用来定义某个类型元素的相等性二元关系。只有有了二元关系，各种集合论中的问题才能解决，比如求并集。这个思路并不是针对和 RM 数据库数据挂钩的对象类型，完全可以应用在更宏观的场合，而在该场合下会可能会无法避免地出现对象的拷贝。以前有人提过一个在用 RM 时遇见的这样的问题，就是找一个方位向量集合中所有重合的方位向量，重合的向量对象在内存中身份不同，但 (x, y) 相同。

另外，如果你说的“佩服你的耐心”是出于属性太多的原因，那在支持反射成员变量的语言中压根儿不是问题。

a19981007a

真相飘过····

越前リョーマ

阿尔西斯永远只有一个——只不过他会分身术！

chaochao

回复 苏小脉 的帖子

在数据库的操作中，Transaction是保证数据正确的手段，而普通的程序是不需要这么做的。Hibernate把数据查询出来挨个比较，挨个比较什么的的完全没有必要吧，不是有HQL嘛……Hibernate实际上也在尽可能避免一些瓶颈。
至于一些特殊情况必须要用副本的，我也是支持用副本的。