我们也意识到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对象(包括验证规则),有人必须把它绑定到那些空闲的控件上.
希望这个想法很清楚,并且提前感谢.
解决方法
您将需要使用Web样式的API来返回JSON以使其易于使用 – 我建议使用新的Web API,因为它可以让您对以前的REST实现中隐藏的HTTP交互进行细粒度的控制WCF
显然,这条路线不是一个银弹 – 你仍然需要关心往返和延迟(这将很容易让您的网络用户界面的复合部分单独调用后端数据,最终以页面形式缓慢渲染).但是在架构上,没有理由这种方法比传统的Web应用程序特别少.
可能的一个缺点是,对于每个页面,将有至少两个往返程序 – 一个是获取HTML JS,另一个用于JS来获取数据 – 使用传统的Web应用程序,只有一个往返来实现相同的因为在首先呈现页面时数据被加载服务器端
