这里有没有人使用DTO将数据从控制器传输到视图?如果是这样,您会在哪里建议存储这些文件? / apps / dtos,然后让他们镜像dir结构的视图?有关使用rspec测试这些动物的任何建议吗?
答案 0 :(得分:7)
Rails约定不是将分布式层用于控制器和视图层。分离是存在的,但与您在Java领域中看到的框架类型相比,它是合乎逻辑且相对较薄/轻量级的。
基本体系结构是控制器设置相应视图中可用的实例变量。在一般情况下,实例变量将是模型实例或模型实例的集合(来自数据库)。模型应该是业务逻辑的核心。控制器协调数据流。视图显示它。帮助器用于格式化视图中的显示值...任何采用模型值并仅用于显示目的的东西(您可能会发现重复使用的辅助方法实际上可能更好地关闭模型本身)。
但是,如果您发现视图需要了解许多不同的模型,您可能会发现在更高级别的抽象中将模型包装到另一个对象中更容易。没有什么可以阻止您创建收集和协调实际AR模型的非活动记录对象。然后,您可以在控制器中实例化这些对象,并使它们可供视图使用。你通常必须在控制器中处于非常密集的复杂程度才能需要这种类型的东西。
我倾向于将这些对象抛到应用程序/模型中--Rails已经加载了这个目录中的所有内容,从配置/期望的角度来看,这样做很容易。
答案 1 :(得分:0)
如果您来自.NET或J2EE背景,您可能会考虑像DTO这样的模式。您可能会或可能不会感到惊讶(并且可能很高兴)了解Rails不按惯例执行此操作。
特别是根本不需要在控制器和视图之间正式传输(或存储)序列化对象。在框架中提供的在控制器中创建的实例变量(通常是模型属性值)可以在框架中免费获得,无需任何额外的编程工作。
答案 2 :(得分:0)
我被告知的一般情况是,这是由“帮助者”处理的工作。它们基本上可以帮助您在视图中格式化模型对象以供视图使用。所以它绝对不是概念的1-1映射,但这是在rails世界中的想法
答案 3 :(得分:0)
请不要听其他答案。他们太可怕了。 Rails助手很糟糕。在任何地方使用rails模型都很糟糕。我求求你,正确设计你的申请,并决定你是否需要DTO。确定您是否确实希望使用rails模型来处理与数据库通信之外的其他事情。决定你是否真的想在你的应用程序和rails之间没有一层,依此类推。 Rails设计仅适用于必须超快速开发的小型应用程序或应用程序。但如果它不是微不足道的并且您希望将其开发一段时间,请将您的时间投入到适当的设计中。不要害怕破坏Rails的便利。可能是你的力量。