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

Question

很多人,我已经开始使用只跟JSON(在我的例子中是Django或Rails)的后端编写越来越多的Web应用程序.

作为前端,我一直在使用MVC客户端,例如Backbone.js.据我所知,这个解决方案非常好用,适用于许多类型的应用程序.

我发现令人讨厌的是我发现自己生成了大量的Javascript代码,几乎完全相同.感觉就像我在每个新应用程序的Backbone上创建一个新层.我在这里思考的方式一定有问题.

让我们举个例子:

假设您有一个API,可以为您提供六个集合,并且您希望使用Twitter Bootstrap来显示此信息.您将拥有一个导航菜单,您可以在其中选择要查看的每个集合.

将会有大量的Javascript代码,只需设置所有模型,集合,视图以及有关路由和导航的逻辑.您还必须考虑哪个视图处于活动状态.

如:

获取集合时的错误处理

如果正在加载集合,我们希望看到"正在加载".如果它失败了,我们就会明白为什么.创建/保存/删除也是如此.

路由

我发现自己编写了一个复杂的逻辑,最终只是呈现了匹配URL的特定视图:s.它只是一个包含所有实例化视图的数组.有时您甚至不需要视图,只需要与URL关联的模板.哦,如果你有六个菜单,你可以有六个功能.但是如果菜单是三级深度,每个菜单上有六个选项,则每个视图都没有路径功能.

导航栏和面包屑

这将是一个从我上面的复杂逻辑中调用的视图.如果导航是多级深度的,那么这可能非常复杂.

我的问题是:我在这里如此独特吗？如果没有,你如何解决这个问题？

Backbone.js不适合我吗？什么选择更适合(哦,是的,我已经搜索过)？

感谢您的时间,我非常感谢您的所有想法.

Answer 1

我想说这里有两个因素:

1. 骨干应用程序很容易变得冗长,因为框架本身非常小而且简单.对于Backbone没有的每个功能和代码行,您必须编写.这是其基本理念的一部分.引用文档:

   Backbone.js的目的是提供共同基础,与雄心勃勃的接口数据丰富的Web应用程序需要 - 虽然很刻意避免通过使,你更好的装备来让自己的任何决定画你到一个角落里.

   所以这是一个权衡.还有其他更全面的框架,如Ember.js 和AngularJS,它们往往会在您自己的代码库中生成更少的样板代码.它们都是顶级框架,您可能需要关注它们.当然,权衡是更大的框架规模,更多的第三方复杂性,以及你将"自己画在角落里"的风险.

   如果您想继续使用Backbone,但您觉得需要从框架中获得更多帮助,请查看Backbone.Marionette.我没有亲自使用它,但对我而言,它看起来是用较少的代码和可维护的结构解决许多常见问题的好方法.

2. 只使用Backbone就可以做得更好.在讨论复杂的,更大的应用程序时,Backbone Model- View- Router模式只能让你到目前为止,Backbone并不是特别擅长向你展示正确的方式.

   当你开始重复代码时,你必须重构,概括并保持干燥.例如:

   • 要在一个位置定义加载图标,请挂钩jQuery.ajax事件或覆盖Backbone.sync.
   • 对于简单的路由操作,定义声明性route->view映射,根据需要使用可选的路由参数和autowire依赖性.使这些分层并基于此地图生成导航视图组件.
   • 你的面包屑挂接到Backbone.history.navigate和路由变化自动映射路径片段本地化的UI文本.

   .

   通过应用一些通用的软件开发模式,将逻辑封装到基类,服务,实用程序,小部件,装饰器,混合器和你拥有的东西,我已经设法让Backbone应用程序从小型50行扩展到5万多个LOC动物.它与大型Rails项目没有什么不同:当应用程序的复杂性和大小增加时,对代码卫生和结构化模式的需求也在增长.

   要在项目之间传输通用解决方案,请从每个项目中创建独立组件.在你提供的例子中,我可以看到一个Backbone.LoadingIndicator,Backbone.Navigation并且Backbone.Breadcrumb很容易形成.为了进一步发展,请使用Bower之类的方法打包组件,并将它们作为依赖项包含在项目中.

您的问题没有正确的答案,但可以肯定地说Backbone应用程序的扩展性远远超出您的描述.它只是希望你进行扩展,作为回报,它可以让你自由地按照构建应用程序的方式构建应用程序,而不是像框架所说的那样.一如既往,选择是你的.