ruby on Rails dto 对象 - 在哪里存储它们？
这里有人使用 DTO 将数据从控制器传输到视图吗？如果是这样，您建议将这些文件存储在哪里？ /apps/dtos，然后让它们镜像视图目录结构？关于用 rspec 测试这些动物有什么建议吗？
Does anyone here use DTO's to transfer data from the controller to the view? If so, where would you recommend storing those files? /apps/dtos, and then let them mirror the views dir structure? Any recommendations on testing these animals with rspec?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
请不要听其他答案。他们太可怕了。 Rails 助手很糟糕。到处使用 Rails 模型是很糟糕的。我恳求您正确设计您的应用程序并决定是否需要 DTO。确定您是否确实希望使用 Rails 模型来处理与数据库通信以外的事务。决定您是否真的不想在应用程序和 Rails 之间有一个层等等。 Rails 设计仅适用于小型应用程序或必须快速开发的应用程序。但如果它不是一件微不足道的事情，并且您希望开发它一段时间，请投入时间进行适当的设计。不要害怕破坏 Rails 的便利性。愿力量与你同在。
Please don't listen to the other answers. They are terrible. Rails helpers are terrible. Using rails models everywhere is terrible. I am begging you, design your application properly and decide if you need DTOs or not. Decide if you actually want to have rails models to handle things other than communication with the database. Decide if you actually want to not have a layer between your app and rails and so on and so forth. Rails design is suitable for only small apps or apps that have to be developed super quickly. But if it's not something trivial and you expect to develop it for some time, please invest your time into proper design. Don't be afraid to break Rails conveniences. And may the force with you.
Rails 约定不使用分布式层作为控制器和视图层。分离是存在的，但与您在 Java 领域看到的框架类型相比，它是合乎逻辑的并且相对薄/轻量级。
基本架构是控制器设置相应视图中可用的实例变量。在一般情况下，实例变量将是模型实例或模型实例的集合（来自数据库）。模型应该是业务逻辑的核心。控制器协调数据流。视图显示它。帮助程序用于格式化视图中的显示值...任何采用模型值并执行某些操作仅用于显示目的的东西（您可能会发现重复使用的帮助程序方法实际上可能对模型本身更好）。
但是，如果您发现视图需要许多不同模型的知识，您可能会发现将模型包装到更高抽象级别的另一个对象中更容易。没有什么可以阻止您创建收集和协调实际 AR 模型的非活动记录对象。然后，您可以在控制器中实例化这些对象，并将它们提供给视图。通常，控制器的复杂性必须达到相当高的水平才能需要这种类型的东西。
我倾向于将此类对象放入应用程序/模型中 - Rails 已经加载了此目录中的所有内容，从配置/期望的角度来看，让事情变得简单。
The Rails convention is not to use distributed tiers for controller and view layers. The separation is there, but it is logical and relatively thin/lightweight compared to the types of frameworks you see in Java land.
The basic architecture is that the controller sets instance variables that are available in the corresponding view. In the general case, the instance variables will be model instances or collections of model instances (coming from the database). Models should be the core of your business logic. Controllers coordinate flows of data. Views display it. Helpers are used to format display values in the view ... anything that takes a model value and does something just for display purposes (you may find that a helper method used repeatedly may actually be better off on the model itself).
However, if you find that a view needs knowledge of many different models, you might find it easier to wrap models into another object at a higher-level of abstraction. Nothing prevents you from creating non-active-record objects that collect and coordinate your actual AR models. You can then instantiate these objects in the controller, and have them available to the view. You generally have to be at a pretty dense level of complexity in the controller to need this type of thing.
I would tend to throw such objects into apps/models - Rails already loads everything in this directory, keeps things easy from a config/expectation point of view.
如果您有 .NET 或 J2EE 背景，您可能会考虑 DTO 等模式。当您得知 Rails 并不按照惯例那样做事情时，您可能会感到惊讶（也可能很高兴）。
特别是，根本不需要在控制器和视图之间正式传输（或存储）序列化对象。在控制器中创建的实例变量（通常是模型属性值）可在框架提供的视图中免费使用，无需任何额外的编程工作。
If you're coming from a .NET or J2EE background you may be thinking about patterns like DTO. You may or may not be surprised (and possibly happy) to learn that Rails doesn't do things that way by convention.
In particular there is no need at all to formally transfer (or store) serialized objects between the controllers and views. Instance variables (typically model attribute values) created in the controller are available within the view for free as provided by the framework without any additional programming effort needed.
据我所知，一般来说，这是由“帮手”处理的工作。它们基本上可以帮助您格式化模型对象，以便从视图中使用视图。所以这绝对不是概念的 1-1 映射，但这就是 Rails 世界的思维
What I've been told is that generally, this is work that is handled by 'helpers'. They basically help you format your model objects for view consumption from within the view. So it's definitely not a 1-1 mapping of concepts, but that's the thinking in the rails world