能有一个视图和一个模型

doreamon999

但更有可能还包含其他内容。 注意：  还存在变体，称为 （模型-视图-呈现器和 （模型-视图 。如果您对此不熟悉并且感觉有很多需要接受的内容，请不要担心。您可能需要一些时间来了解模式，但我在我的在线书籍学习  设计模式中写了有关上述模式的更多内容如果您需要进一步的帮助。   您什么时候需要  框架？  使用  构建单页应用程序时，无论是涉及复杂的用户界面还是只是尝试减少新视图所需的  请求数量，您可能会发现自己发明了构成 框架的许多部分比如  或 。 首先，编写一个应用程序框架并提供一些一些避免意大利面条代码的固执己见的方法并不是非常困难，但是说编写符合  标准的东西同样微不足道，这是一个非常错误的假设。 除了将  操作库、模板和路由捆绑在一起之外，构建应用程序还有很多事情要做。成熟的 框架通常不仅包含您自己编写的许多内容，还包。

含您以后会遇到的问题的解决方案。这是一个节省时间的方法，您不应该低估它的价值。 那么，哪些地方可能需要 框架，哪些地方不需要？ 如果您正在编写一个可能仅与  或后端数据服务通信的应用程序，其中查看或操作该数据的大部分繁重工作将在浏览器中进行，您可能会 Whatsapp 号码列表 发现  框架有用。 属于此类别的应用程序的典型示例是 和 文档。这些应用程序通常会下载一个包含用户执行常见任务所需的所有脚本、样式表和标记的单个有效负载，然后在后台执行许多其他行为。在阅读电子邮件或文档和编写电子邮件或文档之间切换非常简单，而且您根本不需要要求应用程序再次呈现整个页面。 然而，如果您正在构建的应用程序仍然依赖服务器来完成大部分繁重的视图页面，并且您只是使用一点  或  来使事情更具交互性，那么  框架可能会太过分了。当然，在复杂的  应用程序中，视图的部分呈现可以*与单页应用。



程序有效地结合在一起，但对于其他一切，您可能会发现自己最好坚持使用更简单的设置。 网络研讨会：深入了解   的秘密和惊喜！ 保留你的座位 选择的挑战：选择太多？   社区在过去几年中经历了复兴，随着时间的推移，开发人员用它构建了更大、更复杂的应用程序。该语言与软件工程师习惯使用的更经典的语言（++、以及  开发人员使用的语言（、、 等仍然有很大不同。这意味着在许多情况下，我们正在借用过去在其他语言中看到的如何构建应用程序的概念。 在我的演讲“消化  ：模式滥用或进化”中，我提出了这样的观点：当前有太多的选择，当它涉及到使用什么来构建  应用程序。这个问题的部分原因是不同的  开发人员如何解释可扩展的  应用程序应该如何组织——？最有价值球员？ ？还有别的事吗？这导致每周都会创建更多对 有不同看法的框架，并最终产生更多噪音，因为我们仍在努力建立。