出于练习目的，我即将创建一个新的ASP.NET MVC 3.0应用程序。 我的解决方案（Practice.sln）将有4层：
假设我有一个名为“Login”的视图，它在我的Practice.Common层中定义的LoginModel上强类型化。 LoginModel有2个属性（用户名和密码）。
在我的Controller中，当用户提交表单时，我调用以下方法：
[HttpPost]
public ActionResult Login(LoginModel model)
{
if(_service.ValidateUser(model))
return null;
}
ValidateUser（）是我的Pratice.Service层中定义的方法（在我的LoginService.cs文件中）。
我基本上将验证过程委托给我的服务层...
我的问题如下：
考虑到我想尝试/使用会员提供商的好处，并考虑到我的服务层中发生了大多数（如果不是全部）我的逻辑，如何将会员资格移动到我的服务中层？ （如果这是一件好事）
另外......我打算创建自己的成员资格提供者，而不是内置的成员资格提供者，因为我没有使用所有那些生成TABLES和sprocs ......
奖金问题：
最佳做法是将所有登录和帐户管理直接从您的控制器中进行，并将所有其余业务逻辑保存在我的服务层内吗？
我很擅长直接在Controller中发生逻辑“部分”以及服务层中发生的其他“部分”。
当然，如果有人有链接或文章解释这一点，我将不胜感激！
此致
答案 0 :(得分：3)
好的，经过几次试验和更多的阅读后，我已经设法回答了我自己的问题。
至于将成员资格提供程序移动到我的服务层（在我的情况下），这是没有任何意义的，因为我的服务层现在将依赖于System.Web.Security，我不希望这样。
此外，我很快意识到我混淆了两个概念。 FormsAuthentication和Membership。虽然它们是相辅相成的，但我并不需要会员提供的所有方法。因此，我不需要创建自定义成员资格提供程序，也不需要使用内置成员资格提供程序。
我需要做的就是继续在我的服务层创建我的方法（例如Login（）方法），然后手动创建一个FormsAuthenticationTicket，我将在cookie中添加，然后将该cookie添加到cookie中集合（在Controller中）。
作为旁注，我也意识到，只有当你将cookie添加到cookie集合中时，HttpContext.User.Identity.IsAuthenticated才会开始返回TRUE。
就我的奖金问题而言，除非另有说明，否则我会在服务层中保留登录机制（和验证），而不是在Controller中有一些逻辑，在服务层中有一些逻辑。