如何根据对象类型选择视图？
我有 4 个对象（小说、短篇小说、非小说类、科幻小说），所有这些对象都从 Book 基类扩展而来。用户可以查看图书详细信息页面，该页面应根据图书类型显示一组不同的详细信息。因此，理想情况下，我可以有 4 个差异视图脚本，这些脚本将根据所选书籍的类型进行调用。我该怎么做？我应该在每个对象中存储指向视图脚本的链接吗？我应该在控制器操作中使用 switch 语句来确定正确的视图吗？
I have 4 objects (Novel, Short Story, Non-Fiction, Sci-Fi), all of which extend from a Book base class. The user can view a book details page, which should show a different set of details based on the type of book. So, ideally, I could have 4 diff view scripts which would be invoked according to the type of book selected. How would I do this? Should I store a link to the view script within each object? Should I have a switch statement within the controller action to determine the proper view?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
将视图脚本/文件命名为带有详细信息后缀的对象（例如novel_details.php）。
因此，当您显示/渲染视图时，您可以使用详细信息后缀编辑对象的名称
：*这完全取决于您使用的 MVC 框架。
give name to the views scripts/files as your objects with details suffix (e.g. novel_details.php).
So when you display/render a view, you parse the name of the object with details sufix
Edit: *It all depends though which MVC framework you're using.
您是自己实现 MVC 还是使用预先存在的框架？ Rails 类型的框架通常在类/方法和请求之间有一个很好的映射，例如：
GET /book/view/id/1 --> Book::view(1)
根据模型的结构，这可以映射到书籍 GUID；或者，如果您坚持这样的类型层次结构，您可能更喜欢以下内容：
GET /book/view/type/novel/id/3 --> Novel::view(3)其中id指的是小说，而不是书，id。另外：
GET /novel/view/id/3 --> Novel::view(3)的工作方式相同。
也许更切题的是，你应该更喜欢组合而不是继承；有什么理由要拥有4种类型的书吗？它们到底有何不同？如果它们仅在所包含的元数据类型上有所不同，您可能会考虑以某种方式封装该差异，而不是沿着类型层次结构向下移动（例如；如果影响各种类型书籍的方法相似，您可能会只需分解出适用于特定书籍类型的任何算法，并使用对象组合将该功能包含在您的类中）。我认为这还可以让您简化视图结构，从而间接为您提供更清晰的解决方案。
Are you implementing MVC on your own, or using a pre-existing framework? Rails-type frameworks will typically have a nice mapping between classes/methods and requests, e.g.:
GET /book/view/id/1 --> Book::view(1)Depending on the structure of your models, this could map to a book GUID; alternatively, if you insist on such a type hierarchy, you might prefer something like:
GET /book/view/type/novel/id/3 --> Novel::view(3)Where id refers to a novel, rather than a book, id. Also:
GET /novel/view/id/3 --> Novel::view(3)would work identically.
Maybe more pertinently, you should favor composition over inheritance; is there any reason to have 4 types of books? How do they really differ? If they're only differing on the type of meta-data they contain, you might consider encapsulating that difference in some way other than movement down a type hierarchy (for example; if the methods affecting the various types of books are similar, you might simply factor out any algorithm which applies to specific book types and use object composition to include that functionality in your classes). I think this would also allow you to simplify your view structure which, indirectly, would give you a cleaner solution to this problem.
你可以...
然后做类似的事情...
You could have...
And then do something similar to...