默认的AccountController示例何时更改？

我在asp.net论坛上问过这个问题，没有人似乎知道我在说什么。我不知道这是为什么，但我想我会问在这里看看是否有人有一些洞察力。默认的AccountController示例何时更改？

当MVC2发布时，它包含一个示例AccountController，它将内置的Membership和FormsAuthentication类打包为可测试的接口和服务。我阅读了很多这方面的内容，并认为这是一件好事，因为Membership和FormsAuthentication类不容易测试。

最近，我用最新的（SP1，MVC3，工具更新等）环境生成了一个新的示例项目，我发现AccountController现在更简单了。 Interfaces和MembershipService和FormsAuthenticationServices一去不复返了。该示例现在直接调用Membership和FormsAuthentication类。

我想知道是否有人知道这是什么时候发生的，为什么？可测试接口不再被认为是正确的吗？有没有技术上的理由来改变这一点？

我能想到的最好的结果就是，这是作为更改的一部分，以便在打开的URL上传递返回URL时删除可能的漏洞。

任何见解？

来源

2011-07-24 Erik Funkenbusch

账户控制器是用MVC3工具更新（如果它们还包括通过的NuGet使用的jQuery）

来源

2011-07-27 12:50:46 Skuld

谢谢@Skud，这有助于。我承认，通过nuget更新jQuery的能力非常棒。你有什么想法为什么改变了吗？ –

不是线索，禁止他们在那里停止非本地重定向的修复。 asp.net MVC概述页面说：“AccountController改进：Internet项目模板中的AccountController已经大大改进了......”所以谁知道这个“确切”原因是什么。 – Skuld

新模型类似于EF的代码第一种方法，其中AccountModel是POCO类。在新的API中，不再有抽象概念，而是直接调用静态方法，如FormsAuthentication.SetAuthCookie使得这些代码难以进行单元测试。不是我会建议基于您的真实世界的应用程序代码。

而且，是的，他们修复了LogOn方法中的一个漏洞，该漏洞无法验证返回url是否是重定向之前的相对url。

就我个人而言，我会建议您使用抽象来减弱控制器逻辑与其依赖关系之间的耦合。这将使代码更容易进行单元测试。

对于我在不使用视图模型的情况下将所有这些领域模型传递给视图是完全反模式，我从来没有打扰过他们。我只是创建一个空的项目，并按照我的方式做事。我的意思是在默认的项目中，他们甚至为了基督而使用ViewBag！

来源

2011-07-24 21:32:54

所以的AccountController样品由EF 4.1更改变化？这似乎很奇怪。我也很困惑，为什么他们会改变它匹配EF当会员不使用EF，我们不鼓励将我们的会员表添加到我们的模型... –

@Mystere人，不，它不使用EF。它只是匹配AccoutModel是POCO类的相同模型。代码是等价的，因为它们最终调用'SqlMembershipProvider'，它只是直接调用'Membership.ValidateUser'，而在ASP.NET MVC 2中它们使用抽象。 –

对，但我想我的问题是为什么？为什么要回溯到可测试的模型？我希望有人对设计决定有所了解，因为在介绍可测试模型时有很多关于可测试模型的讨论，但是随后他们的变化没有像窥视一样。 –

默认的AccountController示例何时更改？

回答

相关问题