【问题标题】:Membership Provider from inside Service Layer服务层内部的成员资格提供者
【发布时间】:2011-11-14 21:21:18
【问题描述】:

出于练习目的,我将创建一个新的 ASP.NET MVC 3.0 应用程序。 我的解决方案(Practice.sln)将有 4 层:

  • Pratice.Common(我的 ViewModel 的类库)
  • Pratice.Data(EF 类库)
  • Pratice.Service(业务逻辑类库)
  • Pratice.Web(asp.net mvc 3.0 项目)

假设我有一个名为“Login”的视图,它在我的 Practice.Common 层中定义的 LoginModel 上进行强类型化。 LoginModel 有 2 个属性(用户名和密码)。

在我的Controller中,当用户提交表单时,我调用如下方法:

[HttpPost]
public ActionResult Login(LoginModel model)
{
    if(_service.ValidateUser(model))
    return null;
}

ValidateUser() 是在我的 Pratice.Service 层(在我的 LoginService.cs 文件中)中定义的方法。

我基本上将验证过程委托给我的服务层……


我的问题如下:

考虑到我想尝试/使用 Membership Provider 的好处,并且考虑到我的大部分(如果不是全部)逻辑都发生在我的服务层中,如何将会员资格移动到我的服务中层? (如果这甚至是一件好事)

另外……我正计划创建自己的 Membership Provider,而不是内置的,因为我没有使用所有这些生成 TABLES 和 sprocs……

额外问题:

将所有登录和帐户管理直接从控制器中进行,并将我的所有其他业务逻辑保存在我的服务层中是否被认为是最佳实践?

我很好奇将逻辑的“部分”直接发生在控制器内部而其他“部分”发生在服务层中的利弊。

当然,如果有人有解释这一点的链接或文章,我将不胜感激!

真诚的

【问题讨论】:

    标签: asp.net-mvc model-view-controller asp.net-membership


    【解决方案1】:

    好的,经过几次尝试和更多阅读,我已经设法回答了自己的问题。

    至于将 Membership Provider 移动到我的服务层(在我的情况下)这没有任何意义,因为我的服务层现在将依赖 System.Web.Security 而我不希望这样。

    此外,我很快意识到我混淆了两个概念。 FormsAuthentication 和成员资格。尽管它们携手合作,但我并不需要 Membership 提供的所有方法。因此,我不需要创建自定义成员资格提供程序,也不需要使用内置的。

    我需要做的就是继续在我的服务层中创建我的方法(例如 Login() 方法),然后手动创建一个 FormsAuthenticationTicket,我将把它添加到 cookie 中,然后将该 cookie 添加到 cookie集合(在控制器中)。

    顺便说一句,我还意识到只有将 cookie 添加到 cookie 集合中,HttpContext.User.Identity.IsAuthenticated 才会开始返回 TRUE。

    就我的额外问题而言,除非另有说明,否则我会将登录机制(和验证)保留在服务层中,而不是在控制器中保留一些逻辑,在服务层中保留一些逻辑。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2011-12-01
      • 2013-11-04
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多