简单的架构
传统的 Web 端 Java 架构包括 一个用于域对象和数据访问对象的层 一个提供业务级 API 的外观层 一个控制器层和一个视图层 此架构比典型的 模型 视图 控制器 架构（使用 Smalltalk 语言最早创建）稍微复杂一些 相比之下 Ruby on Rails 包括一个使用 ActiveRecord 设计模式的模型层 一个控制器层和一个视图层 我们喜欢易于获得的 Rails 方法 它更加简练并且带来额外的复杂性和错误的机会更小
惯例优先原则
Java 框架通常可以自由地使用 XML 配置 而 Rails 主要使用惯例来避免可能的配置 在程序员必须指定配置的位置 Rails 通常依赖 Ruby（常常以 DSL 形式）来提供配置 对于 green field 开发 我发现惯例优先于配置是很有意义的 该策略为我省去了很多行代码 更简化了必须编写的代码 估计我们所需的配置只有传统 Java 应用程序中所指定的十分之一 我们有时会损失一点灵活性 但这并不足以抵消使用此策略带来的节省
总而言之 Rails 框架的原理适合解决 Ch 项目中的问题 集成的各种工具让我可以利用框架实现更多的功能而无需自己进行过多的集成 惯例优先原则 为我节省了配置站点的时间 动态语言为经验丰富的开发人员提供了更多的能力和灵活性 同时也使他们能够利用更少的代码表达更强大的思想 该框架适合于我们团队的能力和要解决的业务问题
持久性
Java 和 Ruby 语言的最流行的持久性框架可以比任何其他特性更好地阐明 Java 和 Ruby 经验之间的区别 Java 开发人员通常使用 Hibernate 它是一种对象关系映射框架 通过 Hibernate 您可获取现有的模型和模式并使用注释或 XML 表达二者之间的映射 Hibernate 类是简单传统 Java 对象（POJO） 它的每个对象派生自一个通用的基类 大多数配置是显式的 使用注释 XML 或二者的某种结合
而 ActiveRecord 是一种包装的框架 就是说每个类都是现有类的包装器 ActiveRecord 根据关联表的内容（如表中每列的一个属性）自动地向模型对象添加特性 所有的类都从一个通用的基类继承 ActiveRecord 主要利用通用约定来推断配置 例如
ActiveRecord 利用类名的复数形式来推出表名 主键的名称为id列表的排序顺序由position字段决定
对象关系映射是使用遗留模式（可能定义时没有考虑对象模型）时的最佳解决方案 但是当您能为应用程序显式地设计数据库模式时 您通常不需要映射框架了 我们将 ActiveRecord 看作我们的一个巨大优点 我们可以包含关系数据库 需要时转入 SQL 并在适当的时候退出
迁移
Rails 迁移使我们能够用代码表示模式的两个版本之间的差别 和它们所包含的数据之间的差别 对每个迁移都进行了命名和编号 可在任何时候恢复到任何版本 迁移有以下一些确切的优点
产生错误代码时可恢复到一个旧版本的模式 用代码而不是 SQL 来表达模式 更便于我们使用 在最大程度上与数据库独立
但是迁移也有一些限制 如果两个开发人员同时创建迁移 则编号会出现混乱 所以我们必须手动处理 我们通过有效的通信来使这些问题最小化 团队成员构建需使用迁移的新模型时发出通知 但是这个模型依赖于团队的开发人员较少或迁移进展较慢的情况
ActiveRecord 还有其他的限制 其中一些是故意作出的 Rails 的创建者认为 数据库的约束和组成应归入应用程序而不是数据库 这种思想带来了一些副作用 ActiveRecord 使用视图的情况不是很好 构建过程（克隆模式 复制测试数据并运行测试）并不能正确地进行复制 ActiveRecord 在使用参考完整性约束的某些场合也会出现问题 因为某些类型的关联可能连接到多个数据库表 跨越复杂模型进行预先加载很复杂 通常在连接多行时需要使用 SQL 继承也受到限制 使用 ActiveRecord 时 我被迫使用 单表继承映射策略 而该策略并不总是最佳选择
推荐阅读
- pdf如何改变黄色背景，pdf如何改变黄色背景图
- go语言和c语言运行速度，go语言和c语言性能对比
- ios简单的txt阅读软件的简单介绍
- 服务器是日本ip是美国，服务器是日本ip是美国ip
- go语言cat函数 go语言iota
- 包含thinkphp自增入库的词条
- 监控华为服务器，华为服务器管理口远程控制
- 西红柿益智游戏，西红柿手指游戏
- linux路径命令 linux路径表示方法