我是Java用户。最近，我需要为MongoDB构建一个Web项目。根据软件要求，我们必须经常改变收集结构，这意味着没有永久性结构。在为MongoDB尝试了几个Java Object Documentper之后，比如 Morphia 和 MongoDB的Spring数据，我发现那些框架不能支持集合结构的变化。我们事先在类中定义参数，但是如果更新后这些参数不再存在于集合中，或者应该将哪些新参数添加到类文件中，该怎么办？
我的问题是，当集合结构发生变化时，ORM是必需的。这种情况有什么解决方案吗？
答案 0 :(得分：2)
这取决于这些框架的含义，不支持收集结构的变化。如果您已经决定使用Java作为开发语言，那么您已经在某些方面承诺采用相当严格的模式。您可以将您的业务类型建模为地图，然后您只需按名称在地图中填充内容，而您并不关心类型或底层结构。至少在你拿出它们并尝试使用它们之前。您可以手动将Java对象转换为各种驱动程序类型（DBObject或Document），但这可能是一项相当大的工作，并且随着事情的发展而容易出错。
Java几乎迫使你有充分理由考虑类型和结构。随着您的应用程序演变从一个模式转移到下一个模式，Java的类型系统可帮助您找到忘记更新代码以匹配新结构的情况。任何一半不错的IDE都可以帮助你围绕这些新结构进行重构。
同样，使用像Morphia或spring-data这样的ODM可以帮助您将数据输入和输出数据库。根据开发周期的不同，您可能使用旧架构在数据库中拥有数据，但这与您是否使用ODM无关。实际上，使用ODM可以帮助您在代码和应用程序中查找需要查看迁移到新架构的位置。
在数据库级别，您无论如何都需要进行迁移。这通常可以通过mongo shell通过脚本完成，但也可以通过Java和驱动程序完成。通过ODM使用实体类来迁移数据虽然并非不可能，但肯定会很复杂，但这些问题在很大程度上与使用ODM的决策正交。
使用ODM（以及RDBMS系统上的ORM）构建了许多应用程序后，我发现它们在发展架构时过于严格。最终的麻烦实际上是将数据按摩到新的形状。使用ODM实际上将业务代码迁移到新模式几乎是微不足道的。
最终，这是一个偏好问题，归结为您和您的团队所熟悉的内容。就个人而言，我更倾向于使用ODM，而不是依赖基于地图的业务实体或手动将数据传入和传出驱动程序。