默認的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示例何時更改？

回答

相關問題