ASP.NET MVC - 身份验证层在哪里？答案

【问题标题】：ASP.NET MVC - Where does the Authentication Layer go?ASP.NET MVC - 身份验证层在哪里？
【发布时间】：2010-12-04 05:09:38
【问题描述】：

我有一个像这样的 MVC 解决方案设置，包含三个“项目”。

Web（MVC 项目、视图、控制器、视图模型）

模型（领域对象）

持久性（nHibernate 映射、SessionFactory）

我需要开始构建存储库，并且打算从身份验证模型开始。基本上遵循默认的 MVC 模板，有一个 IMembershipService 和一个 IFormsAuthenticationService 和相关的类（使用自定义代码，而不是内置的身份验证提供程序）。

我的问题是……这应该去哪里？我的存储库将需要访问我的域对象和我的持久层。然而，我一直在读到，任何一种“耦合”都意味着它是一个糟糕的设计。所以我犹豫是否要为引用模型/持久性的存储库/服务创建第四个项目......但我真的找不到任何其他合乎逻辑的方法。

【问题讨论】：

标签： asp.net-mvc

【解决方案1】：

这是非常主观的。

做对你和你的团队有意义的事情。

我将它们与我的其他存储库一起放入。我的意思是用户是任何应用程序的核心，对吧？用户是否拥有任何东西？如果是，那他不是根吗？

【讨论】：

我害怕做任何需要我参考解决方案的另一部分的事情。似乎在我转身的任何地方，我所看到的都是人们在谈论与项目的任何部分进行“任何”耦合是多么可怕。在这一点上，对我和我的团队来说，没有什么是真正有意义的——因为如果在某种程度上不耦合到域和映射模型，似乎不可能与数据库进行实际通信。我是否允许应用程序的 Repository 部分查看 SessionFactory？我必须不让所有东西看到其他东西吗？
我不会过分关注程序集引用。事实是它们是耦合的。一个需要另一个才能发挥作用。为了避免滥用技术上可用的和范围内的东西，总是需要一些纪律。
一般来说，如果您的依赖关系朝着一个方向发展，那么您的状态就很好。经验法则是依赖从用户回到持久层（例如表示层 -> 服务层 -> 持久层），但如果你让它们去两个方向或者如果你跳过层，那么你可能会开始遇到问题。

【解决方案2】：

存储库是域的一部分。

在减少程序集引用和最小化项目数量之间总是存在矛盾。也就是说，您可以通过将功能分解为更细粒度的程序集来使每个程序集引用更少的依赖项；但是，将项目过度划分为许多程序集需要更多的管理工作。

另一点值得一提的是，身份验证有几个方面。一个是围绕用户、角色、权限等管理模型——这是一个领域问题。另一个是与执行上下文的接口（无论是 ASP.Net 应用程序、WinForms 等） - 这是一个基础架构问题。因此，我最终在我的 MVC 项目或 WinForms 项目中使用了一个小服务，它执行设置表单身份验证 cookie 或设置当前线程主体等功能。

【讨论】：

【解决方案3】：

Separated interface pattern 表示您的模型和存储库接口应该在一个单独的程序集中，除了 GUI 和实际的存储库实现。这是为了能够在以后切换实现并能够简化测试。

将接口与存储库接口和实际实现放在 mvc 项目或存储库项目中没有问题。如果您使用 IoC 容器，以后移动内容非常容易。

【讨论】：