railsapi跨越边界Rails迁移.doc

rails api 跨越边界 Rails 迁移 ? rails api,跨越边界：Rails迁移 2006年9月25日Ruby onRails是不断发展的Web开发框架，它实现了一些先进的想法，例如通过配置进行约定、大量的元编程、特定于域的语言以及用数据库包装代替对象关系映射。这篇文章研究的Rails模式迁移是一种把每个数据库的模式变化与基本对象模型分离的思想。 作为喜欢冒险的摩托车手，我关注两个严肃的社区：山地摩托车手和公路摩托车手。常规的看法是山地摩托车手更危险，但我并不同意。公路摩托手必须考虑要比石头和树危险得多的障碍：汽车。类似的异议也出现在面向对象应用程序开发使用的两个持久性策略之间。目前，持久性框架使用两种方法中的一种：映射或包装。映射解决方案允许创建独立的数据库模式和对象模型，然后用一个软件层来管理两者间的差异。映射解决方案试图构建一个与数据库模式的结构非常相似的对象模型。与之相反，包装解决方案用对象作为数据库表和行的包装器来操纵数据库中的数据。常规的想法认为在解决方案发布之后，映射解决方案通常更灵活，因为映射软件能够更好地处理模式或对象模型中的变化。但是这个想法忽略了其中最重要的部分：数据。要有效地管理涉及持久性域模型的应用程序变化，必须协调数据、模式和模型的变化。大多数项目团队做不到这一点。开发团队处理模式变化时，通常会用SQL脚本从头开始生成一个新版模式。脚本可能会删除所有的表，再添加所有的表。这样的策略会破坏所有测试数据，因此对于生产场景来说毫无价值。偶尔，工具可能会创建脚本，由脚本生成delta模式，或者生成使用alter_table这样的SQL命令修改以前版本的模式。但是很少有团队会费力气创建能取消模式变化的脚本，而且成功地创建了处理数据变化的自动脚本的团队更少。简而言之，传统的映射策略忽略公路上的汽车：回退坏的模式变化并处理数据。关于这个系列 在跨越边界系列中，作者Bruce Tate倡导这样一个概念：今天的Java程序员可以通过学习其他方式和语言而受益。在编程领域中，Java技术是所有开发项目的最佳选择的情况已经变了。其他框架正在影响Java框架的构建方式，从其他语言学到的概念有助于Java编程。编写的Python(或Ruby、Smalltalk等等)代码可以改变Java编码的方式。这个系列介绍了与Java开发有根本不同，但是却直接适用于Java开发的编程概念和技术。在某些情况下，需要集成这些技术以利用它们。在其他情况下，可以直接应用这些概念。其他语言和框架能够影响Java社区的开发人员、框架甚至基本方式，与此相比，单独的工具并不那么重要。这篇文章深入研究了Ruby onRails迁移--Rails处理生产数据库变化的解决方案。迁移用包装的方式组合了协调模式变化和数据变化的威力和简单性。(如果以前没有学习过活动记录--Rails底层的持久性层，我建议您先阅读跨越边界系列中以前的这篇Rails文章。)在Java编程中处理模式变化 基于映射的框架需要模式、模型和映射。这样的框架是重复性的。请想像一下指定一个属性需要重复多少次：模型中的getter 模型中的setter 模型中的实例变量 映射的to端 映射的from端 列定义 公平地讲，Hibernate这样的Java框架通过代码生成的方式消除了不少重复工作。对象关系映射器可以处理遗留模式，对于新的数据库模式，可以用Hibernate提供的工具直接从模型生成模式并用IDE生成getter和setter。可以用Java标注把映射嵌入域模型，但是按我的观点，这在一定程度上违背了使用映射的初衷。这种代码生成技术还有另一个用途：模式迁移。有些代码生成工具可以发现新的域模型和旧的模式之间的区别，并生成沟通这些不同的SQL脚本。请记住这些脚本处理的是模式，而不是数据。例如，考虑这样一个迁移：把first_name和last_name这两个数据库列合并成叫作name的单一列。来自典型Java持久性框架的工具对数据库管理员没有帮助，因为这些工具只处理问题的一部分：模式中的变化。在进行这个模式变化时，还需要能够处理现有数据。在需要部署这个假想应用程序的新版本时，数据库管理员通常必须手工创建SQL脚本来完成以下工作：创建叫作name的新列。 把first_name和last_name的数据放到新列中。 删除first_name和last_name列。 如果造成模式变化的代码版本仍然处在不完善的状态，那么经常必须手工回退变化。只有很少的团队有这个素养可以集成并自动进行跨模型、模式和数据的变化。Rails迁移基础 在Rails中，所有模式变化--包括模式最初的创建--都在迁移中发生。数据库模式中的每个变化都有自己的迁移对象，迁移对象包装了前进和后退。清单1显示了一个空迁移：我