我已经阅读了很多关于MVP模式的文章.有些人说这太复杂了,有人说它已经过时了.然而对我来说,它似乎是提供单元测试访问UI的完美方式 - 这是我的目标.
你有没有使用过MVP,如果有的话你怎么看?
模型视图演示者,模型视图控制器,传统的三层(UI /业务逻辑/数据存储)或几乎任何其他架构,可隔离代码的各种问题,帮助您编写测试.
通常,架构在某种程度上取决于您的工具:Asp.Net MVP标签似乎表明您已经在那里做出了选择.在任何配置中测试的最棘手的部分是UI,因为即使您创建了一个模拟UI来执行用户可以执行的所有功能......在某些时候您将不得不在浏览器中呈现它并确保理论是声音.
请注意,这并不会影响模拟演示者UI与单元测试的好处,这些单元测试会运用用户将拥有的所有选项:这样做可以让您比单独进行直接UI测试的人多出几年.另一方面,我还没有找到一个程序,其中UI总是按照我们在每个浏览器中的预期呈现.找到这些案例仍然需要人工干预(或者最好是像Selenium或Test Complete一样,一旦你有了初步的贯穿状态).
关于"过时"方面,我认为这是一个红色的鲱鱼.当然有关于架构选择的宗教战争,但是在一些ASP.NET项目中使用MVP的原因是有很多人认为传统的ASP.NET栈在UI和业务逻辑之间过于紧密集成.(我就是其中之一.)对于小型项目来说,紧耦合并不是什么大不了的事,并且通过数据绑定有助于快速"提升并运行"表单设计器的能力.在大型项目中,这些工具的局限性显得匆忙,并且在事实成为挑战之后将"中间"等级重新入侵:一个你不必面对MVP.