我的解决方案(Practice.sln)将有4层:
> Pratice.Common(我的ViewModels的类库)
> 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文件中).
我基本上将验证过程委托给我的服务层……
我的问题如下:
考虑到我想尝试/使用成员资格提供程序的好处,并考虑到我的服务层中发生了大多数(如果不是全部)我的逻辑,如何将成员资格移动到我的服务层? (如果这是一件好事)
另外……我打算创建自己的成员资格提供者,而不是内置的成员资格提供者,因为我没有使用所有那些生成TABLES和sprocs ……
奖金问题:
将所有登录和帐户管理直接从Controller中进行并且我的所有其他业务逻辑保留在我的服务层内是否被视为最佳实践?
我很擅长直接在Controller中发生逻辑的“部分”以及服务层中发生的其他“部分”.
当然,如果有人有链接或文章解释这一点,我将不胜感激!
诚挚
解决方法
至于将成员资格提供者移动到我的服务层(在我的情况下),这是没有任何意义的,因为我的服务层现在将依赖于System.Web.Security,我不希望这样.
另外,我很快意识到我混淆了两个概念. FormsAuthentication和Membership.虽然它们是相辅相成的,但我并不需要会员提供的所有方法.因此,我不需要创建自定义成员资格提供程序也不需要使用内置成员资格提供程序.
我需要做的就是继续在我的服务层中创建我的方法(例如Login()方法),然后手动创建一个FormsAuthenticationTicket,我将在cookie中添加,然后将该cookie添加到cookie集合中(在控制器).
作为旁注,我也意识到,只有当你将cookie添加到cookie集合中时,HttpContext.User.Identity.IsAuthenticated才会开始返回TRUE.
至于我的奖金问题,除非另有说明,否则我会在服务层中保留登录机制(和验证),而不是在Controller中有一些逻辑,在服务层中有一些逻辑.
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。