PubSub/松耦合& JavaScript 中的 MVC 模式
好吧，我是这方面的新手，我一直在尝试研究 Javascript/jQuery 中的 MVC 模式和发布/订阅模式，但是我相信我还没有完全掌握这个概念。
由于我一直在独自完成这件事，所以我谦虚地来这里询问有关我试图遵循这些模式进行的小型教育练习的意见
http://jsfiddle.net/Couto/R62V8/
好吧，练习主要是一个登录表单，其中的值保存在 localStorage 中，同样，它纯粹是教育性的，我现在无论如何都不安全并且不应该在生产中使用它。
您能告诉我您对所使用模式的看法吗？我是否未能正确使用模式？如果需要的话请伤害我，我只是想学习，但我不确定我做得是否正确。
Ok, i'm a newbie in this, i've been trying to study MVC patterns and Publish/Subscription patterns in Javascript/jQuery, however i believe that i haven't grasped the concept entirely.
Since i've been doing it alone, i humbly come here to ask for opinions about a small educational exercise that i tried to make following these patterns
http://jsfiddle.net/Couto/R62V8/
Ok, the exercise is mainly a login form, where the values are saved in localStorage, again it's purely educational, i now it's not safe in anyway and it should not be used in production.
Would you please tell me your opinion about the patterns used, did i fail at achieving the right use of patterns? Please hurt me if needed, i just want to learn, but i'm not sure if i'm doing it right.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
jQuery 的事件委托系统本身就是一种发布/订阅形式。事实上，请检查一下，http://bugs.jquery.com/ticket/7547。您将在幕后看到它使用事件系统，并且实际上仅更改命名方案并在“全局”上下文中工作。
我不反对发布/订阅，但觉得你添加了一个在某些情况下不需要存在的层。在事件委托触发后立即触发正确的函数而不是触发 pub 真的会更糟糕吗？如果您删除订阅和发布，您最终会得到几乎相同的代码，而不会增加“复杂性”。
在其他情况下，发布/订阅很有意义。您的显示/哈希和设置/登录很有意义，因为它们不是其他代码可以订阅/绑定的传统事件的一部分。
人们可能会提出这样的论点：通过在任何地方（包括在事件委托中）使用 pub/sub，您可以抽象出对外部代码的依赖，而无需编写自己的事件委托，这消除了他们对将委托绑定到哪个元素的担忧。如果您正在编写大型复杂的应用程序，请继续将其抽象到该级别。如果您不打算编写大型应用程序，请权衡一下好处，因为 YAGNI 可能适用于此。
jQuery's event delegation system is unto itself a form of pub/sub. In fact check this out, http://bugs.jquery.com/ticket/7547. You'll see under the hood it uses the event system and really only changes the naming scheme and works on a "global" context.
I have nothing against pub/sub, but feel you're adding a layer that doesn't need to exist in certain cases. Would triggering the correct function immediately after the event delegation fires rather than triggering a pub really be worse? If you remove the subscribe and the publish you'd wind up with nearly the same code without the added "complexity".
In other cases the publish/subscribe make a lot of sense. Your display/hash and set/login make a lot of sense as they aren't part of a traditional event that other code could subscribe/bind to.
One could make the argument that by using pub/sub everywhere, including in event delegation, you're abstracting away your reliance on outside code from having to write event delegations of their own, which removes their worry about what element to bind the delegate to. If you're writing big complex applications, go ahead and abstract it out to that level. If you're not planning on writing big applications weigh the benefits cause YAGNI might apply here.