服务层内部的会员提供者

发布于 2024-12-15 05:59:06 字数 981 浏览 1 评论 0原文

出于练习目的,我将创建一个新的 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 个属性(用户名和密码)。

在我的控制器中,当用户提交表单时,我调用以下方法:

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

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

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


我的问题如下:

考虑到我想尝试/使用会员提供程序的好处,并考虑到我的大多数(如果不是全部)逻辑都发生在我的服务中层,如何成员资格移至我的服务层? (如果这甚至是一件好事)

另外......我计划创建自己的会员提供程序而不是内置的,因为我没有使用所有这些生成表和存储过程......

额外问题:

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

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

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

真挚地

For practicing purposes, I’m about to create a new ASP.NET MVC 3.0 application.
My solution (Practice.sln) will have 4 layers:

  • Pratice.Common (class library for my ViewModels)
  • Pratice.Data (class library for EF)
  • Pratice.Service (class library for business logic)
  • Pratice.Web (asp.net mvc 3.0 project)

Let’s assume I have a View called “Login” which is strongly typed on a LoginModel defined in my Practice.Common layer.
The LoginModel has 2 properties (username and password).

In my Controller, when the user submits the form, I call the following method:

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

The ValidateUser() is a method defined in my Pratice.Service layer (inside my LoginService.cs file).

I’m basically delegating the validation process to my Service layer…


My question is the following:

Considering I’d like to try/use the benefits of Membership Provider, and considering that most (if not all) my logic is happening in my Service Layer, how can move Membership into my Service Layer? (if that’s even a good thing)

Also…I was planning on creating my own Membership Provider as opposed to the built-in one since I’m not using all those generate TABLES and sprocs…

Bonus question:

Is it considered best practice to have all the login and account management happening directly from within your Controller and all the rest of my business logic kept inside my Service Layer?

I’m curious in the Pros and Cons of having “parts” of the logic happening directly inside the Controller and other “parts” happening in the Service Layer.

Of course, if anyone has a link or article that explains this, I’d be grateful!

Sincerely

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

恍梦境° 2024-12-22 05:59:06

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

至于将会员资格提供程序移至我的服务层(在我的情况下),这没有任何意义,因为我的服务层现在将依赖于 System.Web.Security,而我不希望这样。

此外,我很快意识到我混淆了两个概念。表单身份验证和会员资格。尽管它们是协同工作的,但我并不需要 Membership 提供的所有方法。因此,我不需要创建自定义会员资格提供程序,也不需要使用内置的会员资格提供程序。

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

附带说明一下,我还意识到,只有将 cookie 添加到 cookie 集合中后,HttpContext.User.Identity.IsAuthenticated 才会开始返回 TRUE。

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

Ok, after a few trials and more reading, I’ve managed to answer my own questions.

As far as moving the Membership Provider to my Service Layer (in my case) that doesn’t make any sense since my Service Layer will now have a dependency on System.Web.Security and I do not want that.

In addition, I quickly realized I was confusing two concepts. FormsAuthentication and Membership. Although they work hand-in-hand, I don’t need all the methods provided by Membership. Therefore, I do not need to create a Custom Membership Provider nor use the built-in one.

All I need to do is to continue to create my methods in my Service Layer (such as a Login() method) and then, manually create a FormsAuthenticationTicket which I’ll add inside a cookie then add that cookie to the cookie collection (in the Controller).

As a side note, I also realized that it is only once you’ve added the cookie to the cookie collection that the HttpContext.User.Identity.IsAuthenticated starts returning TRUE.

As far as my bonus question goes, unless told otherwise, I’ll keep the login mechanism (and validation) in the Service Layer instead of having some logic in the Controller and some logic in the Service Layer.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文