我发现自己在使用Backbone.js或其他MVC时重复了很多代码

I found myself repeat a lots of code when using Backbone.js or other MVC

本文关键字：MVC 代码其他自己发现 js Backbone 更新时间：2023-09-26

和你们中的许多人一样，我已经开始使用只使用JSON（在我的例子中是Django或Rails）的后端编写越来越多的web应用程序。

作为前台，我一直在使用MVC客户端，例如Backbone.js。据我说，这个解决方案非常好，可以很好地与许多类型的应用程序配合使用。

我觉得烦人的是，我发现自己生成了很多做几乎相同事情的Javascript代码。感觉就像我在Backbone上为每个新应用程序创建一个新层。我的思维方式一定有问题。

让我们举一个例子：

假设你有一个API，它给了你六个集合，你想使用Twitter Bootstrap来展示这一点。您将有一个导航菜单，可以在其中选择要查看的每个集合。

将会有很多Javascript代码来设置所有模型、集合、视图以及路由和导航的逻辑。您还必须考虑哪个视图是活动的。

例如：

提取集合时的错误处理

如果正在加载集合，我们希望看到"正在加载"。如果它失败了，我们会看看原因。这与创建/保存/删除相同。

路由

我发现自己写了一个复杂的逻辑，最终只是呈现了一个关于匹配URL:s的特定视图。它只是一个包含所有实例化视图的数组。有时你甚至不需要一个视图，只需要一个与URL相关联的模板。好吧，如果你有六个菜单，你就可以有六个功能。但是，如果菜单有三个层次，每个层次上有六个选项，则不能为每个视图设置路由功能。

导航栏和面包屑

这将是从我上面的复杂逻辑中调用的一个视图。如果导航是多层次的，这可能会非常复杂。

我的问题是：我在这里这么独特吗？如果没有，你如何解决这个问题？

Backbone.js不适合我吗？什么替代品更适合（哦，是的，我已经搜索过了）？

谢谢你抽出时间，我真的很欣赏你所有的想法。

我认为有两个因素在起作用：

主干应用程序很容易变得冗长，因为框架本身又小又简单。对于Backbone没有的每一个功能和代码行，您都必须编写。这是其基本哲学的一部分。引用文件：

Backbone.js旨在为具有雄心勃勃的界面的数据丰富的web应用程序提供所需的共同基础，同时非常刻意地避免做出任何更适合自己的决定，从而将你拖入绝境。

所以这是一种权衡。还有其他更全面的框架，如Ember.js和AngularJS，它们往往在您自己的代码库中生成更少的样板代码。它们都是一流的框架，你可能想看看。当然，权衡的是更大的框架大小、更高的第三方复杂性，以及你将"把自己画在角落里"的风险。

如果您想继续使用Backbone，但又觉得需要该框架提供更多帮助，请查看Backbone.Marionete。我个人没有使用过它，但对我来说，它看起来是一种用更少的代码和可维护的结构解决许多常见问题的好方法。
只有Backbone你可能会做得更好。Backbone Model-View-Router模式只能让您在谈论复杂、更大的应用程序时走到这一步，而Backbone并不是特别擅长向您展示正确的方法。

当你开始重复代码时，你必须重构、泛化并保持它的干燥。例如：
- 要在一个位置定义加载图标，请挂接到jQuery.ajax事件或覆盖Backbone.sync
- 对于定义声明性route->view映射的简单路由操作，请根据需要使用可选的路由参数和autowire依赖项。使这些具有层次结构，并基于此地图生成导航视图组件
- 将面包屑连接到Backbone.history.navigate，并在路线更改时自动将路线片段映射到本地化的UI文本
通过应用一些通用的软件开发模式，将逻辑封装到基类、服务、实用程序、小部件、装饰器、mixin以及其他什么中，我已经成功地将骨干应用程序从50个小的线性程序扩展到了50000多个LOC野兽。这与大型Rails项目没有什么不同：当应用程序的复杂性和规模增加时，对代码卫生和结构化模式的需求也会增加。

要在项目之间传输通用解决方案，请从每个项目中创建独立的组件。在您提供的示例中，我可以很容易地看到Backbone.LoadingIndicator、Backbone.Navigation和Backbone.Breadcrumb的形成。要进一步做到这一点，请使用类似于Bower的东西来打包您的组件，并将它们作为依赖项包含在您的项目中。

你的问题没有正确的答案，但可以肯定地说，Backbone应用程序的规模远远超出了你所描述的范围。它只是希望你进行扩展，作为回报，它让你可以自由地按照应用程序需要的方式构建应用程序，而不是按照框架所说的那样。一如既往，选择权在你。