2

We are trying to make up our minds where to start with a new project of upgrading our website. As we have upgraded our old back-end system in .NET we really want to keep working in C# for many reasons like (but not limited to) TFS integration, the development environment, and testing, Azure integration, integrated security, proper documentation, etc.

What we also know we want to accomplish is to start with a web based API and consume our own services, first on a regular website, later also on mobile devices. We have been playing around with WCF (OData enabled) Data services and the new Web API which comes with MVC4.

My personal preference is working with the Data Services, as more of the OData standard is implemented, like the $select option, which makes the API we would create very simple and extremely useful, and we can ensure we only request the data we use from the client, in JSON, XML, and probably other formats we will not immediately use.

Now as our first project will be to implement a website that consumes either the Data service, or the Web API, which frameworks should we look at to consume the services from the client side. Ideally we would like to serve the website from another machine and have the client to connect to the API using Ajax (or JSONP) to read from the service (in a later stage also the CUD actions).

For creating the new website we want to buy a set of tools, and we have evaluated Telerik, DevExpress and Ext.NET, but none of these seem as compatible with either of these services as they claim on their site (but perhaps I am missing something). We want to try to stay away of creating our own javascript.

I guess my questions are the following:

  • Which of the techniques for the API is better and why? DataService seems to be quite old - will it still be supported in the future? Is there a third option I should evaluate?
  • Did someone choose to take on a similar project and can you share your experiences?
  • Which of the frameworks of Telerik, DevExpress, Ext.NET or any other is more useful to consume any of these APIs from the client side?
  • Should we use WebForms or MVC and why?
4

1 回答 1

2

对于我们最近做的一个项目，我们完全避免使用商业第三方库 - 出于各种原因：我们对它们与开源库的比较没有留下深刻印象（出于明显的原因不是 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 接口完成所有工作。此外，暴露后端数据源或 API 会暴露实现细节，并不是好的软件工程。

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

WebForms 已死，而 ASP.NET MVC 是未来。您将针对它编写的代码将更加清晰、有条理和连贯。删除“控件”、生命周期、视图状态都简化了事情并消除了许多 ASP.NET 的巫术（例如在 Page_Load 之后添加的控件会发生什么）。我再也不想在我的生活中看到 WebResource.axd（它使在旅途中调试和自定义客户端脚本变得非常困难）。

坏消息是，如果您或您的团队没有太多以“正确方式”做事的经验（即不使用 HTML 的可视化设计器，做过多的 DataBinding，或者只是<asp:DataGrid>在页面上乱搞），那么您将遇到困难在你改掉坏习惯时挣扎。

HTH。

于 2012-07-02T15:48:59.217 回答