我们正在努力决定从哪个地方开始升级我们网站的新项目。由于我们已经在.NET中升级了旧的后端系统，我们真的希望继续使用C＃，原因很多，例如（但不限于）TFS集成，开发环境和测试，Azure集成，集成安全性，适当的文档，等
我们还知道，我们要完成的是从基于Web的API开始，使用我们自己的服务，首先是在常规网站上，后来也是在移动设备上。我们一直在使用WCF（支持OData）数据服务和MVC4附带的新Web API。
我的个人偏好是使用数据服务，因为实现了更多的OData标准，比如$ select选项，这使得我们创建的API非常简单且非常有用，我们可以确保我们只请求数据我们使用客户端，JSON，XML，以及我们不会立即使用的其他格式。
现在，我们的第一个项目是实现一个消耗数据服务或Web API的网站，我们应该考虑哪些框架来使用客户端的服务。理想情况下，我们希望从另一台机器上提供服务，并让客户端使用Ajax（或JSONP）连接到API以从服务中读取（在稍后的阶段也是CUD操作）。
为了创建新网站，我们想要购买一套工具，我们已经评估了Telerik，DevExpress和Ext.NET，但这些服务似乎都不像他们在网站上声称的那样兼容（但也许我错过了什么）。我们希望尽量不要创建自己的javascript。
我想我的问题如下：
答案 0 :(得分：2)
对于最近的一个项目，我们完全避免了商业第三方库 - 出于各种原因：我们对它们与开源库（不是GPL）的比较印象深刻，原因很明显，但主要是BSD / Apache），但也因为我们尝试做的很多事情都非常简单，而且构建我们自己的平台的速度和学习现有平台一样快，然后花时间让它做什么我们想要。
对于我们的后端API，我们使用针对WCF编写的完全RESTful服务。它使用我们自己的POCO数据契约对象返回纯粹简单的XML - 这意味着我们可以非常快速，轻松地使用多种语言（包括使用jQuery的.NET，PHP和Javascript）开发自己的客户端。像瘟疫一样避免使用SOAP。然而，我们花了很多年才让WCF以适当的REST方式工作 - 如果我们从一开始就做项目，那么我们可能会编写自己的RESTful Web服务器，它位于HTTP.SYS之上，而不是插入到IIS中。它有时会使事情变得复杂（例如，我们的服务使用HTTP基本身份验证进行访问控制，这是IIS喜欢介入的内容）。然后还有＆＃34;基本URL＆＃34; IIS和WCF公正的地方。 IIS中的WCF需要在用户友好性方面进行工作。
对于客户端，我们可以选择允许Javascript直接连接到服务，但我们没有看到真正的性能提升，最终我们决定让脚本通过网站自己的AJAX完成所有工作接口。此外，暴露后端数据源或API揭示了实现细节，并不是一个好的软件工程。
出于上面提到的原因，我们避开了客户端框架。如果您熟悉XHTML / CSS，那么您可以轻松编写自己的基于Web的小部件，并确保它们是为您的应用程序构建的。我看到太多的应用程序只是在页面上散布了Telerik / DevExpress / etc控件，结果是由于所有导入的客户端脚本文件和资源导致的缓慢，麻烦的混乱。
WebForms已经死了，ASP.NET MVC就是未来。你反对它的代码将更加清晰，有条理，连贯。删除＆＃34;控件＆＃34;，生命周期，viewstate都可以简化事情并消除很多ASP.NET的伏都教（例如在Page_Load之后添加的控件会发生什么）。我再也不想在我的生活中看到WebResource.axd了（这使得在运行中调试和自定义客户端脚本非常困难）。
坏消息是，如果您或您的团队没有多少经验，那就是“正确的方式”＃34; （即不使用HTML的可视化设计器，进行过多的DataBinding，或只是在页面上进行<asp:DataGrid>），那么当你忘记了坏习惯时，你将面临艰难的挣扎。
HTH。