拥有没有控制器或视图的资源是一种不好的做法吗？ （导轨）
我有一个资源，只是一个模型：我正在构建一个应用程序，它具有与 Twitter 时间线和提及系统类似的功能。提及的类没有相应的控制器或任何视图。按照我构建它的方式，每当发布消息时都会创建提及。在创建消息之前，会扫描用户名并为每个用户创建一个提及实例。这种情况发生在消息和提及模型中。 或者，对于那些用户不直接交互的资源，这种仅模型的情况是否合适？
这是我的第一个 Rails 应用程序，我仍在学习 MVC 和 REST，所以我想我做错了很多事情。什么是合适的架构？
I have one resource that is only a model: I am building a an app which has a similar thing to the Twitter timeline and mentions system. The mentions class has not a correspondent controller or any views. The way I built it, mentions are created whenever a message is posted. Before the message being created, it is scanned for usernames and creates a mention instance for each one of them. This happens all in the messages and mentions models.
Or is this model-only situation fine for those resources with which users dont interact directly?
This is my first rails app, and I am still learning MVC and REST, so I guess I am doing a lot of things wrong. What would be a proper architecture for this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您的数据不需要单独的控制器或视图，那么您的应用程序就是这样。
也就是说，通过 RESTful 映射（如果您的应用程序需要它）来公开嵌套模型通常很方便，以避免过度急切的获取 - 但同样，这是否有意义是特定于应用程序的。
If you have data that doesn't need a separate controller or view, then that's just the way your app is.
That said, it's often handy to expose even nested models via a RESTful mapping (if you app requires it) to avoid over-eager fetching--but again, whether or not that makes sense is app-specific.
我参与过许多项目，其中有用作连接表的模型，但没有相应的控制器或视图。听起来这就是你在这里做的事情，所以我不会担心。
有时您会拥有控制器和视图，但没有相应的模型，反之亦然。
I have worked on many projects where there are Models that are being used as Join tables and do not have corresponding Controllers or Views. Sounds like that's what you are doing here so I wouldn't worry about it.
Sometimes you will have a Controller and Views without having a corresponding Model for them, and vice versa.