2010-07-19 62 views

回答

7

Rails约定不是为控制器层和视图层使用分布式层。分离就在那里,但与Java领域中看到的框架类型相比,它是合乎逻辑的,相对较薄/轻量级的。

基本架构是控制器设置在相应视图中可用的实例变量。在一般情况下,实例变量将是模型实例或模型实例(来自数据库)的集合。模型应该是您业务逻辑的核心。控制器协调数据流。视图显示它。 Helpers用于在视图中设置显示值的格式......任何需要模型值并仅仅为了显示目的而执行某些操作的东西(您可能会发现重复使用的辅助方法实际上可能更适合模型本身)。但是,如果您发现某个视图需要许多不同模型的知识,则可能会发现将模型封装到另一个更高级别的对象中更容易。没有什么能阻止你创建收集和协调实际AR模型的非活动记录对象。然后,您可以在控制器中实例化这些对象,并让它们可用于视图。你通常必须在控制器中处于相当密集的复杂程度才能需要这种类型的东西。

我倾向于将这些对象放入应用程序/模型 - Rails已经加载了这个目录中的所有东西,从配置/期望的角度来看可以让事情变得简单。

+0

谢谢托比。这需要一点习惯,但我有点看到这个想法。我赞赏这个明确的答案。 – 2010-07-20 16:51:37

0

如果您来自.NET或J2EE背景,您可能会考虑类似DTO的模式。您可能会也可能不会感到惊讶(也可能很高兴)得知Rails不按照惯例那样做事。

尤其没有必要在控制器和视图之间正式传输(或存储)序列化的对象。在控制器中创建的实例变量(通常是模型属性值)在框架提供的视图中可用,无需任何额外的编程工作。

0

我被告知的一般情况是,这是由'助手'处理的工作。他们基本上可以帮助你设置模型对象的格式,以便从视图中消费视图。所以它绝对不是概念的1-1映射,但这就是rails世界的想法

1

请不要听其他的答案。他们很可怕。 Rails助手很糟糕。在任何地方使用rails模型都很糟糕。我求求你,正确设计你的应用,并决定你是否需要DTOs。决定是否真的想要rails模型来处理与数据库通信以外的其他事情。决定你是否真的不想在你的应用和导轨之间有一层,等等。 Rails设计仅适用于需要快速开发的小应用程序或应用程序。但是,如果它不是微不足道的,并且您希望开发一段时间,请将您的时间投入到适当的设计中。不要害怕打破Rails的便利。并可能与你的力量。