asp.net - .NET 中的 Web 开发 - 使用哪些技术来构建和使用您自己的 API？

Question

我们正在努力决定从哪里开始升级我们网站的新项目。由于我们已经在 .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。

我想我的问题如下:

• 哪种 API 技术更好？为什么？数据服务 似乎很老了 - 将来还会支持它吗？是 我应该评估第三个选择吗？
• 有人选择承担类似的项目吗？您能分享一下您的经验吗？
• Telerik、DevExpress、Ext.NET 或任何其他框架哪个更 从客户端使用这些 API 有用吗？
• 我们应该使用 WebForms 还是 MVC？为什么？

Answer 1

对于最近的一个项目，我们完全避免使用商业第三方库 - 出于各种原因:我们对它们与开源库的比较印象不深(出于明显的原因不是 GPL，但主要是 BSD/Apache) ，但也因为我们尝试做的很多事情都非常简单，构建我们自己的平台与学习现有平台然后花时间让它做我们想做的事情一样快。

对于我们的后端 API，我们采用了针对 WCF 编写的完全 RESTful 服务。它使用我们自己的 POCO 数据契约对象返回纯粹且简单的 XML - 这意味着我们可以非常快速、轻松地以多种语言(包括 .NET、PHP 和使用 jQuery 的 Javascript)开发我们自己的客户端。像躲避瘟疫一样避开 SOAP 。然而，我们花了很长时间才让 WCF 以正确的 RESTful 方式工作 - 如果我们从一开始就做这个项目，那么我们可能会编写自己的 RESTful Web 服务器，它位于 HTTP.SYS 之上，而不是插入 IIS它有时不必要地使事情变得复杂(例如，我们的服务使用 HTTP 基本身份验证进行访问控制，IIS 喜欢介于两者之间)。此外，还存在 IIS 和 WCF 相互较量的“基本 URL”问题。 IIS 中的 WCF 需要提高用户友好性。

对于客户端，我们可以选择允许 Javascript 直接连接到服务，但我们没有看到真正的性能提升，最终我们决定让脚本通过网站自己的 AJAX 接口(interface)来完成所有操作。此外，暴露后端数据源或 API 会暴露实现细节，并不是好的软件工程。

出于我上面给出的原因，我们避开客户端框架。如果您擅长 XHTML/CSS，那么您可以轻松编写自己的基于 Web 的小部件，并确保它们是为您的应用程序构建的。我见过太多的应用程序只是在页面上散布 Telerik/DevExpress/etc 控件，结果由于所有导入的客户端脚本文件和资源而导致缓慢、繁琐的困惑。

WebForms 已死，ASP.NET MVC 才是 future 。您将根据它编写的代码将更加干净、有组织且连贯。删除“控件”、生命周期、 View 状态都简化了事情并消除了许多 ASP.NET 的巫术(例如在 Page_Load 之后添加的控件会发生什么)。我再也不想在生活中看到 WebResource.axd(它使得随时随地调试和自定义客户端脚本变得非常困难)。

坏消息是，如果您或您的团队没有太多以“正确方式”做事的经验(即不使用 HTML 可视化设计器、进行过多的数据绑定(bind)，或者只是在页面上添加 <asp:DataGrid>)那么当你改掉坏习惯时，你将经历一场艰苦的斗争。

HTH。