为了获得一些观点,我们一直在使用ASP.NET Web表单.
我们也意识到MVC相对于Web表单的好处,然而另一个选择是绕过所有这些抽象层,只是从纯.HTML页面转到WCF服务.
没有.ASPX,没有.cshtml/.vbhtml,只是纯.HTML文件,以避免服务器端逻辑和渲染.这是一些人提出的想法,并且对HTML5及其功能越来越有吸引力.通过完全控制HTML来定位更多设备的能力也是一个驱动因素.
我知道从技术角度来看它是可行的 - 尤其是jQuery让事情变得如此简单 - 但是我担心通过抛弃整个服务器端的抽象(Web窗体中的代码隐藏,MVC中的控制器和视图绑定)我们最终会做更多的管道,我们以前不必担心.
问题归结为:
注意:我使用术语"企业级别"来强调这不是一个简单的网页应用程序,其中有几个页面,其中底层架构的最终决定是无关紧要的,我们在这里谈论大屁股app :)
编辑:为了更清楚,我们在这种方法中关注的主要领域是:
身份验证和授权 - > MVC使用属性(例如AuthorizeAttribute)以非常简单的方式处理这个问题,但这种"静态"方法意味着WCF必须处理令牌,加密/解密它们,并决定谁可以执行所有操作在每次通话中保持所有这些信息的同时.这是唯一的解决方案吗？
关注点分离 - > MVC显然可以做到这一点,并且我可以添加它.然而,这种方法迫使您在HTML中明确地写入需要WCF函数调用的内容.因此,您的表示层不仅要处理要绘制的内容,还要在其中嵌入要调用以获取其数据的逻辑,以及如何在页面中分发它.这可能不是什么大问题,但相比之下,MVC中的ViewBag为您提供了将WCF服务URL作为动态属性的选项,这意味着逻辑现在是控制器的一部分,而不是您的HTML页面.改变这种逻辑可以免除完全通过HTML页面的麻烦.
绑定和验证 - >我把这两个放在同一个篮子里,因为最终一旦WCF服务响应了一个JSON对象,其中包含我的页面需要运行的所有信息(包括验证规则),有人必须将它绑定到那些空闲的控制.
希望这个想法足够清楚,并提前感谢.