是 [HTML5 + jQuery]（无 ASP.NET）+ WCF 是企业级 Web 应用程序的有效解决方案吗？
为了获得一些视角，我们已经使用 ASP.NET Web 表单很长时间了。
我们也意识到 MVC 相对于 Web 表单的优势，但是正在考虑另一种选择，即绕过所有这些抽象层，只从纯 .HTML 页面转到 WCF 服务。
没有 .ASPX，没有 .cshtml / .vbhtml，只有纯 .HTML 文件，以避免服务器端逻辑和渲染。这是一些人提出的想法，并且随着 HTML5 及其特征。通过完全控制 HTML 来定位更多设备的能力也是一个驱动因素。
我知道从技术角度来看这是可行的 - 特别是 jQuery 使事情变得更加容易 - 但我担心通过抛弃整个服务器端抽象（Web 表单中的代码隐藏，MVC 中的控制器和视图绑定）我们最终会做更多以前不必担心的管道工程。
问题归结为：
- 这是一个合理的担忧吗？如果是的话，我们最终会做什么样的管道工程？
- 如果将整个 ASP.NET 框架（从 Web 应用程序一侧）扔到一边，而仅仅依靠纯 HTML 页面与 WCF 服务的直接通信，我们究竟会损失什么？
注意：我使用“企业级”一词来强调这不是一个只有几个页面的简单 Web 应用程序，其中底层架构的最终决策无关紧要，我们在这里谈论的是大屁股应用程序:)
< em>编辑：为了更清楚，我们在这种方法中关心的主要领域是：
身份验证和授权 --> ; MVC 使用属性以非常简单的方式处理此问题（例如 AuthorizeAttribute），但是，这种“静态”方法意味着 WCF 必须处理令牌、加密/解密它们，并决定谁可以自行执行所有操作，同时在每个过程中维护所有这些信息。 称呼。 这是唯一的解决方案吗？
关注点分离 --> MVC 显然做到了这一点，而且我可以补充说，它做得非常好。然而，这种方法迫使您在 HTML 中显式编写需要调用哪个 WCF 函数。因此，表示层不仅处理要绘制的内容，还嵌入了调用什么来获取数据以及如何在页面中分发数据的逻辑。这可能不是什么大问题，但相比之下，MVC 中的 ViewBag 使您可以选择将 WCF 服务 URL 作为动态属性，这意味着逻辑现在是控制器的一部分，而不是 HTML 页面。更改该逻辑可以免除浏览 HTML 页面的麻烦。
绑定和绑定验证 -->我将这两个放在同一个篮子中，因为最终一旦 WCF 服务使用包含我的页面运行所需的所有信息（包括验证规则）的 JSON 对象进行响应，就必须有人将其绑定到那些空闲控件。
希望这个想法足够清晰，并提前致谢。
To gain some perspective, we've been using ASP.NET web forms for ages.
We're also aware of the benefits of MVC over web forms, however an alternative option is being tossed around which is to bypass all of those abstraction layers and just go from a pure .HTML page to the WCF service.
No .ASPX, no .cshtml / .vbhtml, just pure .HTML files in order to avoid server side logic and rendering. That's the idea being suggested by some, and is becoming more appealing with HTML5 and its features. The ability to target more devices by having full control over the HTML is also a driving factor.
I know that it's feasible from a technical point of view - especially with jQuery making things so much easier - but I'm worried that by tossing the whole server side abstraction (code-behind in web forms, controller and view-binding in MVC) we'll end up doing more plumbing which we didn't have to worry about previously.
The question boils down to:
- Is that a valid concern, and if so what kind of plumbing might we end up doing?
- What is it exactly that we could lose by tossing the whole ASP.NET framework aside (from the web application's side) and just relying on direct communication to our WCF service from pure HTML pages?
N.B: I used the term 'enterprise level' to emphasize that this is not a simple web-app with a few pages where the ultimate decision of the underlying architecture is irrelevant, we're talking big ass app here :)
Edit: In order to be even clearer, the main areas that are of concern to us in such an approach are:
Authentication and Authorization --> MVC handles this in a very straightforward way with attributes (e.g. AuthorizeAttribute), this 'static' approach however means the WCF will have to handle tokens, encrypt/decrypt them, and decide who gets to do what all on its own while maintaining all of this information throughout every call. Is this the only solution?
Separation of Concern --> MVC clearly does that, and does it very well might I add. This approach however forces you to explicitly write in your HTML which WCF function call is needed. So not only is your presentation layer handling what to draw, it also has embedded in it the logic of what to call to get its data, and how to distribute it in the page. This may not be such a big deal, but in contrast the ViewBag in MVC gives you the option to have your WCF service URLs as a dynamic property, meaning that logic is now part of your controller and not your HTML page. Changing that logic exempts the hassle of going through HTML pages altogether.
Binding & Validation --> I've put these two in the same basket because ultimately once the WCF service responds with a JSON object containing all the info my page needs to function (including validation rules) someone's gonna have to bind it to those idle controls.
Hope the idea is clear enough, and thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您还没有“抛弃整个服务器端抽象”，您正在以不同于标准 Web 应用程序的方式对功能进行分区。服务器端抽象现在来自 WCF 服务，该服务向表示层提供数据。
您将需要使用 Web 样式 API 来返回 JSON 以使其易于使用 - 我建议为此使用新的 Web API，因为它为您提供对 HTTP 交互的细粒度控制，这在 WCF 中以前的 REST 实现中有些隐藏，
显然，走这条路线并不是灵丹妙药 - 您仍然需要关心往返和延迟（很容易将复合Web UI 的各个部分是分开的调用后端获取数据，最终导致页面渲染速度非常慢）。但从架构上来说，这种方法没有理由比传统的 Web 应用程序限制更少。
可能的一个缺点是，每个页面至少有两次往返 - 一次获取 HTML + JS，另一个让 JS 获取数据 - 对于传统的 Web 应用程序，只有一次往返来实现与首先渲染页面时在服务器端加载数据相同
You haven't "tossed the whole server side abstraction" you are partitioning the functionality differently from a standard web application. The server side abstraction now comes from the WCF service which is supplying data to the presentation tier
You will need to use Web style APIs to return JSON to make it easy to consume - and I'd suggest using the new Web API for that as it gives you fine grained control over the HTTP interaction that was somewhat hidden in previous REST implementations in WCF
Obviously going this route is not a silver bullet - you will still need to care about round-trips and latency (it would be very easy to have composite parts of your web UI making separate calls to the backend for data which ends up with pages very slow to render). But architecturally there is no reason that this approach is particularly less limiting than having a traditional web application.
Probably the one downside is that for each page there are going to be at least two roundtrips - one to get the HTML + JS and the other for the JS to get the data - with a traditional web app there is only one roundtrip to achieve the same as the data is loaded server side when rendering the page in the first place
您可以查看一些更高级的 js 库，例如 KendoUI ，它将完成大部分的管道工作你。您可以享受一些非常酷的功能，ASP.NET 开发人员曾经使用服务器端代码来实现这些功能，而仅使用客户端代码来实现开箱即用。该框架仍在开发中，您可以期待更多酷炫功能的出现。
免责声明：我在 Telerik 工作，虽然没有直接参与该产品，但我们也在内部使用它。我既不是销售团队的人员，也不是开发人员的人员 - 我只是认为这正是您所需要的。
You can check out some more advanced js libraries like KendoUI for example, that will do the biggest part of the plumbing for you. You can enjoy some really cool features, that ASP.NET developers have used to do with server-side code, out-of-the-box only with client side code. The framework is still in development and you can expect more cool features to come out.
dislaimer: I work at Telerik, although not directly engaged in the product and we also use it internally. I'm neither from the sales team nor from the development - I just think it is just what you need.