数据库模板表应该提供哪些CRUD资源？
想象一下有一个 Web 应用程序可以跟踪同时阅读多本书的作业。例如，如果书籍 A & B 有 16 章，C 书有 32 章，那么要在 16 周内读完所有三本书，一个人需要每周阅读 A 书和 C 书 1 章。 B 书每周 2 章，C 书每周 2 章。
当用户创建自己的阅读计划时，应用程序将复制阅读计划模板以创建每周的实际作业。每个作业将包含基于用户提供的开始日期的截止日期。每项作业还将以一对多的方式链接到该周要阅读的每一章，以便用户可以在每章的基础上跟踪每周需要阅读的四个章节中每一章的进度。
问题
- 即使用户不会创建单独的作业，我是否应该为作业提供“创建 CRUD”资源？
- 我是否应该只为阅读计划提供创建 CRUD 资源，然后该资源将遍历模板作业并将其复制到该用户的阅读计划作业中？
这是一个 Ruby on Rails 3.1 应用程序。
Imagine a web application to track assignments for reading multiple books at once. For instance, if books A & B have 16 chapters and book C has 32 chapters, then to complete all three books in 16 weeks a person would need to read 1 chapter per week for books A & B and 2 chapters per week for book C.
When a user creates their own reading plan, the application would copy the reading plan template to create actual assignments for each week. Each assignment would contain a due date based on the user provided start date. Each assignment would also be linked on a one-to-many basis to each chapter to be read that week, so that the user can track their progress on a per chapter basis for each of the four chapters required to be read each week.
Questions
- Should I provide the Create CRUD resource for assignments, even though users won't create individual assignments?
- Should I just provide the Create CRUD resource for a reading plan, which would then go through and copy the template assignments to that user's reading plan assignments?
This is a Ruby on Rails 3.1 application.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
除非您确实时间/资源紧张，否则我建议提供直接的 CRUD 功能，即使它们可能仅限于某些管理员/超级用户配置文件。
根据我的经验，无论设计多么出色，应用程序迟早都会需要一些快速而肮脏的绕过功能来直接修改较低级别的数据。
Unless you are really strapped for time/resources, I'd suggest to provide direct CRUD functionalities, even if they may perhaps restricted to some admin/superuser profile.
No matter how brilliantly designed, an application sooner or later will need some quick&dirty bypass functionality to directly amend data at a lower level, in my experience.
您应该将用户体验 (UX) 重点放在用户想要/需要做什么：创建
阅读计划。用户不关心（也不应该需要关心）您的内部架构建模业务问题。
复杂输入的常见模型是“向导”，它在用户填写小表格或回答问题时引导用户完成许多连续步骤。这可能对这里有帮助。
您可能需要为各种表提供额外的增删改查接口，以供您自己的管理使用。但对于用户本身来说，关注他们对问题的看法，而不是你对问题的看法。
如果他们认为阅读计划由许多作业组成，那么作业对他们来说可以作为计划的一部分可见。 -- 但是将作业作为可扩展部分放在每个阅读计划的单个 html 页面上 -- 人们很难在屏幕之间保持精神状态。
You should focus the User Experience (UX) on what the users want/need to do: creating
reading plans.Users don't care (and shouldn't need to care) about your internal architectural modeling of the business problem.
A common model for complicated input is the "wizard" which steps the user through a number of sequential steps as they fill out small forms or answer questions. That may be of help here.
You might want additional crud interfaces to various tables for your own administrative uses. But for the users themselves, focus on their view of the problem, not your view of it.
If they think of a reading plan of consisting of a number of assignments, then the assignments could be visible to them as part of the plan. -- But put the assignments as expandable sections on a single html page per reading plan--people have a hard time maintaining mental state between screens.