我是否应该将BackBone.js实现到ASP.NET WebForms应用程序中？
背景
我正在努力改进我的团队目前的web应用程序开发模式。我们目前的模式是我们试图在ASP.NET WebForms之上丰富web应用程序时提出的(我们都不知道ASP.NET MVC)。这是当前的模式：
好了！
- 我们的应用程序正在使用WinForms框架。
- 我们的ASPX页面本质上只是HTML，我们几乎不使用WebControls。
- 我们使用JavaScript/jQuery来执行所有UI事件和AJAX调用。
- 对于单个ASPX页面，我们有一个.js文件。
- 我们所有的AJAX调用都是POST(根本不是RESTful )
- 我们的AJAX调用了在一系列ASMX文件中定义的联系人WebMethods。
- 每个业务对象一个ASMX文件。
为什么要改变？
我想修改一下我们的模式，原因有几点：
- 我们开始发现我们的JavaScript文件变得有点笨重。
- 我们正在使用大量的方法来保持本地数据和DOM更新的同步。我们似乎花了太多的时间来编写代码来保持同步，调试可能会变得很棘手。
我一直在阅读开发Backbone.js应用程序，我非常喜欢骨干网在代码组织和关注点分离方面提供的内容。然而，我已经进入了RESTful应用程序的章节，我开始对使用主干感到有些犹豫。
问题
问题是我们的WebMethods并不真正适合RESTful模式，这似乎是骨干想要使用它们的方式。
现在，我只想谈谈我们的客户端代码混乱的问题。我想避免对我们的WebMethods进行重大重写。
我的问题
是否可以使用主干(或类似的库)来清理我们的客户端代码，而不是主要影响我们的数据访问WebMethods？还是试图以这种方式使用主干网是一种私生惯用呢？
有谁能在代码组织和减少编写DOM和数据同步代码的时间方面改进我们的模式呢？
回答 1
Software Engineering用户
发布于 2012-12-03 17:33:57
这在很大程度上取决于您是如何设计和编写代码的，但是可以对您的应用程序进行改造以允许使用Backbone.js (不，我认为这不一定是一种私生子行为)。
你需要做的是把你的电话翻译成你的web服务可以理解的东西。有两种可能的方法可以做到这一点：
- 创建一个发送和接收REST调用的服务器端API包装器。基本上，您将创建一个“API”/“路由器”类，与骨干应用程序进行接口。此API将其余调用转换为web服务所理解的内容。然后，它将来自the服务的信息转换回骨干应用程序理解的RESTful响应。(如果您的WebMethods可以直接从服务器上的其他函数(IE - "var foo = bar.GetData()“或其他任何函数)调用，这是非常容易的。
- 用自己的方法覆盖主干的同步方法。也可以使用您自己的内置同步函数。这样做将允许您构建一个同步函数集，该函数集可以理解您正在发送和接收的数据的类型。这将将应用程序中的其余命令(get、set、update、delete)转换为符合您的web服务的命令。
我个人建议，如果可能的话，在您的服务器端代码周围放置一个包装器，这样您就可以在将来更新它，而不必再重复您的客户端代码。但是，如果您必须选择选项2的路线，请尝试编写您的主干应用程序的其余部分，就像您的RESTful服务是一个web一样，这样，一旦您转换了服务器，就可以轻松地用普通的Backbone.Sync替换您的Backbone.Sync函数。
https://softwareengineering.stackexchange.com/questions/178166
复制相似问题
腾讯云开发者
