我们也意识到MVC对Web表单的好处,然而一个替代方案是绕过所有这些抽象层,从纯HTML页面到WCF服务.

没有.ASPX,没有.cshtml / .vbhtml,只是纯粹的.HTML文件,以避免服务器端的逻辑和渲染.这是一些被建议的想法,并且随着HTML5及其功能的变得越来越吸引人.通过完全控制HTML来瞄准更多设备的能力也是一个驱动因素.

我知道从技术的角度来说,这是可行的 – 尤其是jQuery使事情变得更容易 – 但是我担心的是,通过抛出整个服务器端抽象(Web窗体中的代码隐藏,MVC中的控制器和视图绑定)我们最终会做更多的管道,我们以前没有担心.

这个问题归结为：

>这是一个有效的关注,如果是这样,我们最终会做什么样的管道？
>我们可以通过将整个ASP.NET框架抛在一边(从Web应用程序的侧面),只是依靠从纯HTML页面直接与我们的WCF服务进行通信,这是什么？

N.B：我使用“企业级”一词强调,这不是一个简单的网页应用程序,其中几个底层架构的最终决定是无关紧要的,我们在这里谈论大屁股应用程序:)

编辑：为了更加清晰,我们在这方面所关注的主要领域是：

>认证和授权 – > MVC以非常直接的方式处理这个属性(例如AuthorizeAttribute),但是这种“静态”方法意味着WCF将不得不处理令牌,加密/解密它们,并且决定谁能够自己完成所有操作,同时保持所有这个信息遍布每一个通话.这是唯一的解决方案吗？
分离关注 – > MVC明确地表示,我可以补充一点.然而,这种方法迫使你明确地写入你需要的WCF函数调用的HTML.因此,您的演示层不仅可以处理要绘制的内容,还会嵌入其中调用以获取其数据的逻辑,以及如何将其分发到页面中.这可能不是一个大问题,但与MVC中的ViewBag相比,您可以选择将WCF服务URL作为动态属性,这意味着逻辑现在是控制器的一部分,而不是HTML页面.改变逻辑可以免除HTML页面的麻烦.
>绑定&验证 – >我把这两个放在同一个篮子里,因为一旦WCF服务响应一个包含我的页面需要的功能的所有信息的JSON对象(包括验证规则),有人必须把它绑定到那些空闲的控件上.

希望这个想法很清楚,并且提前感谢.