我在 4 个月前开始学习如何构建 N 层 Web 应用程序，但我仍然不完全了解将所有内容放在哪里。我的架构基于 Scott Millett 的“Professional ASP.NET Design Patterns”一书，如下所示:
- 项目. Controller
- 项目.基础设施
- 项目.模型
- Project.Repository.NHibernate
- 项目.服务
- 项目.UI.Web.MVC
在他的案例研究中，他在他的基础设施项目中使用了标准的成员(member)资格提供商。如果我想创建另一个 Web 应用程序，我可以轻松地将基础设施项目添加到解决方案中，并准备好成员资格以供使用。
但我想创建我自己的使用 NHibernate 的自定义成员身份提供程序。我应该在我的服务项目中为它创建一个服务并在我的 Repository.NHibernate 项目中为它创建一个存储库吗？还是我仍然应该使用基础设施项目并在其中创建它们，以便我可以在其他项目中重用它？
最佳答案
不要过度设计您的解决方案，这些事情没有真正的对错之分。做最简单的事情来解决您的问题并交付功能。
所以最大的问题是当您可以使用 SqlMembershipProvider 来实现同样的事情时为什么要这样做(当然除非您要更改使用 aspnet_regsql 命令创建的表结构)
无论如何，抛开问题不谈，我倾向于遵循 Microsoft 的命名空间约定。因此，在您的情况下，我会在您的解决方案中创建一个名为 YourCompany.Web.Security 的新类库，然后在名为 YourCompany.Web.Security.HibernateMembershipProvider 的命名空间中创建 Provider 类。您的所有存储库和服务以及其他垃圾都将放入此程序集中。
现在您遇到的更大问题是关于数据存储的学术问题。根据我的经验，最好不要将身份和“一般”配置文件数据放在与应用程序数据相同的数据库中。所以这个新程序集应该检查你正在连接的数据库实例并创建表等来支持你的成员需求(假设你正在实现一个完整的提供者)
您可能还需要编写自己的网络/Windows 应用程序来管理用户。
所以当所有这些都已经存在于 SqlMembershipProvider 时，我真的会质疑你正在做的事情的值(value)。
综上所述，关于调查 .net 4.5 的新 Microsoft Identity Foundation (WIF) 功能和使用 azure 来管理您的身份数据，还有很多话要说。设置非常简单。
关于c# - 我应该在我的项目架构中的什么位置放置自定义成员资格提供程序？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14175191/