从UI层抽象asp.net mvc标识

我正在构建一个新的MVC应用程序。通常，我总是有一个项目结构，看起来像这样：从UI层抽象asp.net mvc标识

DAL层（实体库
服务层（该API /前端和DAL）
前端之间的协调面向业务的服务电话，这可以是网络API或MVC应用程序

我的问题是，我总是以凌乱的用户管理实现结束，我使用了成员资格提供程序，因此使该部分不如它应该好。看到了新的身份实施和我真实我喜欢它。我做了一些关于hot的搜索以将其抽象到后端，但没有结果。

我发现这个职位如何组织该项目，但它没有给出真正的答案：Decoupling ASP.NET MVC 5 Identity to allow implementing a layered application

我希望有人能为我提供一些提示或技术文件如何抽象的所有登录和验证到后端层。

2014-01-23 Patrick

您可以在业务层中创建一个非常基本的界面。这将是这个样子：

public interface IAuthenticationService 
{ 
    bool VerifyPassword(User user, string password); 

    bool SignIn(User user); 

    void SignOut(); 
}

您可以实现无论是在业务层，UI层或一个单独的基础设施层使用ASP.NET身份这个接口。

该接口可以通过不同的技术实现，这些技术可以在运行时通过IoC容器注册，例如，您可以使用接口AccountController。由于认证框架往往会变化（每年左右），这使您可以更轻松地进行切换。

来源

2014-01-23 13:02:07

但是，我怎样才能使用我的控制器中的属性以及如何实现oauth？ – Patrick

@Patrick如果您的意思是['Authorize']（http://msdn.microsoft.com/zh-cn/library/system.web.mvc.authorizeattribute（v = vs.118）.aspx）属性，您可以只要使用它，ASP.NET身份就会考虑到它。它位于'System.Web.Mvc'命名空间中，因此它对认证实现没有直接的依赖关系。关于OAuth，我没有经验，所以我不确定是否可以将它抽象出来。 –

只是好奇有人真的把它拉掉了吗？这听起来很简单，但由于EF Identity实现包含在账户控制器中的扩展方法，我所下的路线可能会造成如此混乱。我从字面上试图达到我可以完全从我的MVC项目中提取EF，Identity和EF Identity依赖项的程度。只是想看看有没有人有过这方面/最佳实践的例子，因为我可能不得不重新开始。 – Shawn

从技术上讲，它已经被抽象化了。 UserManager类是ASP.NET Identity的核心，它是数据库上下文的包装。现在，如果您正在讨论进一步抽象，所以在您的代码中根本没有提及ASP.NET Identity，我认为这是不必要的，但仍然有可能。您只需将所有代码移动到您的服务层，然后拨打您的服务即可打到UserManager上的适当方法。尽管如此，你仍然需要传递你的上下文，所以你最终不会创建它的多个实例，肯定会对你产生影响。

来源

2014-01-23 14:07:56

我不想摆脱我的代码中的asp.net身份。只有在mvc项目中摆脱它，并将其放入服务层项目中。也许我应该开始将控制器中的所有代码移动到服务器上，然后看看接下来应该做什么。 – Patrick

@Patrick如果将UserManager放入服务层，则必须从数据层传递dbContext（或IdbContext），这是错误的。你有解决方案吗？ – Arvand

从UI层抽象asp.net mvc标识

回答

相关问题