mvc2 mvc

There's no shortage of JavaScript MVC (Model-View-Controller) architectures out there. The best-known is Backbone, but there are others: Spine, Agility, Knockback, etc. And in addition to the range of MVC frameworks, there are MV-whatever variants. This stuff, anecdotally, is pretty popular. As of this writing, Backbone is the 7th most watched repo on GitHub. Developers love MVC.

那里不乏JavaScript MVC(模型-视图-控制器)架构。 最著名的是Backbone ，但还有其他一些： Spine ， Agility ， Knockback等。除了MVC框架范围之外，还有MV变体。 有趣的是，这种东西很受欢迎。 在撰写本文时，Backbone是GitHub上第七大最受欢迎的仓库。 开发人员喜欢MVC。

What makes MVC so appealing, especially for JavaScript where it's still primarily used, on the client? If you're new to application architectures, it's definitely very accessible - the model is data, the view is.. the view, and the controller makes them do stuff. Easy! If you started coding on the server-side, MVC is probably already familiar. Most Object-Oriented Programming embraces the pattern and you can find very popular MVC frameworks for Java, .NET, Python, PHP, etc. The pattern itself actually predates and was first implemented in Smalltalk, after being invented by Trygve Reenskaug in the late 70s, so its relationship with OOP has been there from the beginning. Given the unquestioned supremacy of OOP until fairly recently, it's unsurprising that MVC makes immediate sense to many of us.

是什么使MVC在客户端上如此吸引人，尤其是对于仍主要使用它JavaScript而言？ 如果您是应用程序体系结构的新手，那么绝对可以轻松访问它-模型是数据，视图是..视图，控制器使它们可以完成工作。 简单！ 如果您开始在服务器端进行编码，那么MVC可能已经很熟悉了。 大多数面向对象的程序设计都包含该模式，您可以找到非常流行的Java，.NET，Python，PHP等MVC框架。该模式实际上早于70年代后期由Trygve Reenskaug发明，并最初在Smalltalk中实现。 ，因此与OOP的关系从一开始就存在。 鉴于直到最近，OOP一直是至高无上的，所以MVC对我们许多人立即具有意义就不足为奇了。

JavaScript, however, is not exactly OOP. We can do OOP with it, but the two hardly go hand-in-hand. Therefore, the appropriateness of MVC varies by use case. For data entry, content management systems, and situations where we can pick out clear and obvious "models", it tends to work very nicely. But where the state of an application is more amorphous and not always tracked in the same place, in applications with lots of user interaction before any data actually changes, and in apps with very complex widgets or complex, it's less clear that it's the right choice. And if your site is JS-heavy but still static, obviously, forget it. There's no benefit in doing all that setup on a page that's going to reload and lose it all.

但是，JavaScript并不是完全面向对象的。 我们可以用它做OOP，但是两者很难并存。 因此，MVC的适用性因使用案例而异。 对于数据输入，内容管理系统以及我们可以挑选出清晰明显的“模型”的情况，它往往工作得很好。 但是，在应用程序的状态更加不确定并且不总是在同一位置进行跟踪的情况下，在实际更改任何数据之前具有大量用户交互的应用程序中，以及在具有非常复杂的小部件或复杂性的应用程序中，不清楚这是正确的选择。 而且，如果您的站点是JS密集型的，但仍然是静态的，那么显然，就算了。 在要重新加载并丢失所有内容的页面上进行所有设置没有任何好处。

The issue we run into when talking about MVC, or any other architectural pattern, is that, as web developers, these things were not created for us. We can trace the most common patterns back to Design Patterns (aka the Gang of Four book), which was published in 1995. The dawn of our field, literally. These patterns were for programmers building programs primarily for their own use, and certainly not for programmers whose work was easily revealed by going up to the menu and clicking View Source. While those patterns all made their way in some form to the back-end, that canon predates JavaScript completely.

在谈论MVC或任何其他架构模式时，我们遇到的问题是，作为Web开发人员，这些东西并不是为我们创建的。 我们可以将最常见的模式追溯到1995年出版的《 设计模式》 (又名《四人帮》一书)。 这些模式仅适用于程序员主要供自己使用的程序，而不适用于那些通过转到菜单并单击“查看源代码”即可轻松显示其工作的程序员。 尽管这些模式都以某种形式进入了后端，但该规范完全早于JavaScript。

MVC, though, was one of the few ancient methods that made immediate sense. Because it has a clear place for the UI to exist, it's easily applied to the front-end (although, again, that application is not canon). Because any pattern we want to use has to be fudged a bit to get it to fit our context, MVC is a great place to start. But it's not the only option we have.

但是，MVC是为数不多的立即可行的古老方法之一。 因为它有明确的UI放置位置，所以很容易将其应用于前端(尽管同样，该应用程序不是佳能)。 因为我们想要使用的任何模式都必须经过一些摸索才能使其适应我们的环境，所以MVC是一个很好的起点。 但这不是我们唯一的选择。

It seems fair to call Event-Driven Architectures the second most obvious pattern. We use event-driven patterns all over the place in JS, and even in combination with MV* patterns. They work well where we need a lot of messaging, and have less need for clear-cut, classical "objects". For the objects we do have, getters and setters (and soon, Object.observe()) can be used as publishers and subscribers, decoupling events, the core of the application, from the things they affect. The value, though, is that these decoupled events don't need to affect only objects, but can also affect the DOM, or server interactions, or other events, and none of that needs to be packaged up in a Model-View-Controller triad if it doesn't make sense as one.

将事件驱动的体系结构称为第二最明显的模式似乎很公平。 我们在JS各处都使用事件驱动的模式，甚至与MV *模式结合使用。 它们可以在需要大量消息传递的地方很好地工作，并且对清晰，经典的“对象”的需求较少。 对于我们确实拥有的对象，可以将getter和setter(以及不久后的Object.observe() )用作发布者和订阅者，将事件(应用程序的核心)与事件的影响解耦。 不过，其价值在于，这些解耦的事件不必只影响对象，还可以影响DOM或服务器交互或其他事件，并且这些都不需要打包在Model-View-Controller中。如果没有任何意义，则使用三合会。

The Naked Objects pattern bears closest relation to MV*, and it would not be unfair to call it a variant of Presentation-Abstraction-Control (a more distant relative). This one's good for big meaty widgets that need to contain and render their own data, and whose visual representation maps directly to the data they contain. It bears similarity to the drag-and-drop IDEs we used to use to build desktop applications, but without the drag-and-drop bit. Rebecca Murphey used a similar pattern in building the Mulberry mobile app framework, which is a perfect use case because Naked Objects is a great way of organizing a composable framework whose implementations will be better served by a different pattern.

Naked Objects模式与MV *有最密切的关系，因此称其为Presentation-Abstraction-Control的变体(相对更远的亲戚)并不是不公平的。 这对于需要包含和呈现自己的数据且视觉表示直接映射到它们包含的数据的大型小部件很有用。 它与我们用来构建桌面应用程序的拖放式IDE相似，但没有拖放位。 丽贝卡·穆菲(Rebecca Murphey)在构建Mulberry移动应用程序框架时使用了类似的模式，这是一个完美的用例，因为Naked Objects是组织可组合框架的好方法，该框架的实现可以通过不同的模式更好地实现。

The third pattern I think deserves more examination is Pipelines. This should be familiar to jQuery developers or anyone who deals with a lot of callbacks. Pipelines chain operations together to affect a shared state, which might be a visual representation or just a set of data (or both!). The interesting thing to me is that we can use this pattern both synchronously and asynchronously, for example applying global functions to initialize, render, and wire-up a page, then use instance-specific functions to wait for user interaction, validate it, attempt to save it, and render again, all the while modifying the state of an abstraction of that page. Anything with a state can have a corresponding state diagram in code, with the ability to modify the path it takes depending on the result of each step.

我认为值得更多研究的第三个模式是管道 。 jQuery开发人员或处理大量回调的任何人都应该熟悉这一点。 管道将操作链接在一起以影响共享状态，共享状态可以是可视化表示，也可以只是一组数据(或两者都有！)。 对我来说有趣的是，我们可以同步和异步使用此模式，例如，应用全局函数来初始化，呈现和连接页面，然后使用特定于实例的函数来等待用户交互，验证并尝试保存并再次渲染，同时修改该页面的抽象状态。 具有状态的任何内容都可以在代码中具有相应的状态图，并且可以根据每个步骤的结果来修改其所采用的路径。

With all of these, as with MVC or any other pattern, you have to consider how and where you want your application tightly or loosely coupled, and whether you need a centralized snapshot of the application, or it's better stored in the components it affects. Things like Naked Objects would be overkill if even your most complex controls are only used once. Things like EDA would be pointless if most of your code is setup and initialization code. And if your site is static, whatever introduces the least framework code while still helping you establish clear conventions would be preferable.

对于所有这些，与MVC或任何其他模式一样，您必须考虑将应用程序紧密或松散耦合的方式和位置，以及是否需要应用程序的集中快照，或者最好将其存储在受影响的组件中。 如果只使用一次您最复杂的控件，则诸如Naked Objects之类的东西就显得过大了。 如果您的大多数代码是设置和初始化代码，则EDA之类的事情将毫无意义。 而且，如果您的站点是静态的，则在引入最少框架代码的同时仍能帮助您建立明确约定的任何方法都是可取的。

At the end of the day, you should still use Backbone rather than not use anything. However, if you find yourself with an application that fits more easily into some other pattern, you shouldn't be afraid to use it. Sadly, for most of these patterns (and the myriad I haven't even mentioned), you're going to have a hard time finding anything as robust and accessible as Backbone. So, more importantly, if you're sitting down to write a new JS application framework, you'd do all of us a service by exploring an alternative to MVC, so picking the right tool for the job won't be a matter of choosing from a selection of nice hammers with different brandnames to tighten screws. Whatever you choose, and whatever the application, though, remember that all implementations decay and it's just as important to leave the opportunity to improve architecture as it is to leave ways to improve the code itself.

最终，您仍然应该使用Backbone，而不要使用任何东西。 但是，如果您发现自己的应用程序更容易适应其他模式，则不要害怕使用它。 可悲的是，对于大多数这些模式(以及我什至没有提到的无数种模式)，您将很难找到像Backbone一样健壮且易于访问的任何内容。 因此，更重要的是，如果您坐下来编写一个新的JS应用程序框架，那么我们将通过探索MVC的替代方案为我们所有人提供服务，因此选择适合该工作的工具将不是问题从具有不同品牌的精美锤子中选择，以拧紧螺丝。 但是无论您选择什么，无论使用什么应用程序，都请记住，所有实现都会衰减，并且留下改进架构的机会与留下改进代码本身的方式一样重要。

翻译自: https://davidwalsh.name/beyond-mvc

mvc2 mvc