MVC之外的世界
那里不乏JavaScript MVC（模型-视图-控制器）架构。 最著名的是Backbone ，但还有其他一些： Spine ， Agility ， Knockback等。除了MVC框架范围之外，还有MV变体。 有趣的是，这种东西很受欢迎。 在撰写本文时，Backbone是GitHub上第七受关注的仓库。 开发人员喜欢MVC。
是什么使MVC在客户端上如此吸引人，尤其是对于仍主要使用它JavaScript而言？ 如果您是应用程序体系结构的新手，那么绝对可以轻松访问它-模型是数据，视图是..视图，控制器使它们可以完成工作。 简单！ 如果您开始在服务器端进行编码，那么MVC可能已经很熟悉了。 大多数面向对象的程序设计都包含该模式，您可以找到非常流行的Java，.NET，Python，PHP等MVC框架。该模式本身实际上早于70年代末由Trygve Reenskaug发明，并最初在Smalltalk中实现。 ，因此与OOP的关系从一开始就存在。 鉴于直到最近，OOP一直是至高无上的，所以MVC对我们许多人立即具有意义就不足为奇了。
但是，JavaScript并不是完全面向对象的。 我们可以用它做OOP，但是两者很难并存。 因此，MVC的适用性因使用案例而异。 对于数据输入，内容管理系统以及我们可以挑选出清晰明显的“模型”的情况，它往往工作得很好。 但是，在应用程序的状态更加不确定并且不总是在同一位置进行跟踪的情况下，在任何数据实际更改之前具有大量用户交互的应用程序，以及具有非常复杂的小部件或复杂的应用程序中，不清楚这是正确的选择。 而且，如果您的网站是JS密集型的，但仍然是静态的，那么显然，就算了吧。 在要重新加载并丢失所有内容的页面上进行所有设置没有任何好处。
在谈论MVC或任何其他架构模式时，我们遇到的问题是，作为Web开发人员，这些东西并不是为我们创建的。 我们可以将最常见的模式追溯到1995年出版的《 设计模式》 （又名《四人帮》一书）。 这些模式仅适用于程序员主要供自己使用的程序，而不适用于那些通过转到菜单并单击“查看源代码”即可轻松显示其工作的程序员。 尽管这些模式都以某种形式进入了后端，但该规范完全早于JavaScript。
但是，MVC是为数不多的立即可行的古老方法之一。 因为它有明确的UI放置位置，所以很容易将其应用于前端（尽管同样，该应用程序不是佳能）。 因为我们想要使用的任何模式都必须经过一些捏造才能使其适合我们的环境，所以MVC是一个很好的起点。 但这不是我们唯一的选择。
将事件驱动的体系结构称为第二最明显的模式似乎很公平。 我们在JS的各处甚至甚至与MV *模式结合使用事件驱动模式。 它们可以在需要大量消息传递的地方很好地工作，并且对清晰，经典的“对象”的需求较少。 对于我们确实拥有的对象，可以将getter和setter（以及不久后的Object.observe() ）用作发布者和订阅者，将事件（应用程序的核心）与事件的影响解耦。 不过，其价值在于，这些解耦的事件不必只影响对象，还可以影响DOM或服务器交互或其他事件，并且这些都不需要打包在Model-View-Controller中。如果没有任何意义，则使用三合会。
Naked Objects模式与MV *有着最密切的关系，因此称其为Presentation-Abstraction-Control的变体（相对更远的相对）并不是不公平的。 这对于需要包含和呈现自己的数据且视觉表示直接映射到其包含的数据的大型小部件很有用。 它与我们用来构建桌面应用程序的拖放式IDE相似，但是没有拖放式位。 丽贝卡·穆菲（Rebecca Murphey）在构建Mulberry移动应用程序框架时使用了类似的模式，这是一个完美的用例，因为Naked Objects是组织可组合框架的好方法，该框架的实现可以通过不同的模式更好地实现。
我认为值得进一步研究的第三个模式是管道 。 jQuery开发人员或处理大量回调的任何人都应该熟悉这一点。 管线将操作链接在一起以影响共享状态，共享状态可以是可视化表示，也可以只是一组数据（或两者都有！）。 对我来说有趣的是，我们可以同步和异步使用此模式，例如，应用全局函数来初始化，呈现和连接页面，然后使用特定于实例的函数来等待用户交互，验证并尝试保存并再次渲染，同时修改该页面的抽象状态。 具有状态的任何内容都可以在代码中具有相应的状态图，并且可以根据每个步骤的结果来修改其所采用的路径。
对于所有这些，与MVC或任何其他模式一样，您必须考虑将应用程序紧密或松散耦合的方式和位置，以及是否需要应用程序的集中快照，或者最好将其存储在受影响的组件中。 如果只使用一次您最复杂的控件，则诸如Naked Objects之类的东西就显得过大了。 如果您的大多数代码是设置和初始化代码，则EDA之类的事情将毫无意义。 而且，如果您的站点是静态的，则在引入最少框架代码的同时仍能帮助您建立明确约定的任何方法都是可取的。
最终，您仍然应该使用Backbone，而不要使用任何东西。 但是，如果您发现自己的应用程序更容易适应其他模式，则不用担心使用它。 可悲的是，对于大多数这样的模式（以及我什至没有提到过的无数种方式），您将很难找到像Backbone一样健壮和易于使用的东西。 因此，更重要的是，如果您坐下来编写一个新的JS应用程序框架，那么我们将通过探索MVC的替代方案为我们所有人提供服务，因此，选择适合该工作的工具将不是问题从具有不同品牌的精美锤子中选择，以拧紧螺丝。 无论您选择什么，无论使用什么应用程序，都请记住，所有实现都会衰减，并且留下改进架构的机会与留下改进代码本身的方式一样重要。
