默认的AccountController示例何时更改？

Question

我在asp.net论坛上提出了这个问题，但似乎没有人知道我在说什么。我不确定为什么会这样，但我想在这里问问是否有人有一些见解。

早些时候，MVC2发布时包含了一个示例AccountController，用可测试的接口和服务包装了内置的Membership和FormsAuthentication类。我读了很多关于这个的文章，因为Membership和FormsAuthentication类不容易进行测试，所以这被认为是一件好事。

最近，我使用我的最新环境（SP1、MVC3、工具更新等）生成了一个新的示例项目，发现AccountController现在简单得多。接口、MembershipService和FormsAuthenticationServices都消失了，示例现在直接调用Membership和FormsAuthentication类。

我想知道这是何时发生的，为什么会这样？可测试的接口不再被认为是正确的吗？改变这种做法是否有技术原因？

我能想到的最好的解释是，这是为了消除在传递返回URL时可能存在的漏洞而进行的更改。

有什么见解吗？

- Erik Funkenbusch

Answer 1

新模型类似于EF的Code First方法，其中AccountModel是一个POCO类。在新API中，不再有抽象层，而是直接调用静态方法，例如FormsAuthentication.SetAuthCookie，使得代码难以进行单元测试。我不建议您基于这个编写真实应用程序代码。

是的，他们已经修复了LogOn方法中的漏洞，在重定向之前未验证返回URL是否为相对URL。

个人建议您使用抽象层来减弱控制器逻辑和其依赖项之间的耦合。这将使代码更容易进行单元测试。

对我来说，在不使用视图模型的情况下将所有领域模型传递给视图是完全错误的做法，我从未关注过它们。我只是创建一个空项目，并按照自己的方式完成任务。我的意思是，在默认项目中，他们甚至使用ViewBag！

- Darin Dimitrov

---

那么 AccountController 的示例被 EF 4.1 更改了吗？这似乎相当奇怪。我也很困惑，为什么他们会将其更改以匹配 EF，而 Membership 不使用 EF，并且我们被劝阻将 Membership 表添加到我们的模型中... - Erik Funkenbusch

@Mystere Man，不，它不使用EF。它只是匹配相同的模型，其中AccoutModel是一个POCO类。代码是等效的，因为它们都最终调用SqlMembershipProvider，只是新模型直接调用Membership.ValidateUser，而在ASP.NET MVC 2中，它们使用了一个抽象。 - Darin Dimitrov

没错，但我想问的是为什么？为什么要在可测试模型上倒退？我希望有人知道设计决策的内情，因为当引入可测试模型时，有很多讨论，但后来它们被改变了，却没有任何声音。 - Erik Funkenbusch

@Mystere Man，老实说，我不知道ASP.NET MVC团队为什么决定改变AccountController，使其更难进行单元测试，并与ASP.NET基础设施类（如FormsAuthentication）更紧密地耦合。也许是为了使代码更短。实际上，应用TDD的人并不关心默认的ASP.NET MVC项目。他们只是简单地进行TDD。对于其他所有人（对我来说，这些人占大多数），他们决定提供一些易于理解的模板，并在没有太多麻烦的情况下运行一些应用程序。好吧，麻烦稍后会成为SO问题 :-) - Darin Dimitrov

Answer 2

随着MVC3工具更新（同时包括通过Nuget使用jQuery），账户控制器也进行了更改。

- Stephen

---

谢谢@Skud，这很有帮助。我承认，通过nuget更新jQuery的能力非常棒。你知道为什么做出这个改变吗？ - Erik Funkenbusch

除了他们放置的修复程序以防止非本地重定向外，我一无所知。asp.net MVC概述页面说：“AccountController改进：Internet项目模板中的AccountController已经得到极大的改进”...所以谁知道这样做的“确切”原因是什么。 - Stephen