4 个月前我开始学习如何构建 N-Tier Web 应用程序，但我仍然不完全了解将所有内容放在哪里。我的架构基于 Scott Millett 的《Professional ASP.NET Design Patterns》一书，如下：
在他的案例研究中，他在基础设施项目中使用了标准的会员资格提供程序。如果我想创建另一个 Web 应用程序，我可以轻松地将基础设施项目添加到解决方案中，并准备好使用会员资格。
但我想创建我自己的使用 NHibernate 的自定义成员资格提供程序。我应该在我的 Services 项目中为它创建一个服务并在我的 Repository.NHibernate 项目中为它创建一个存储库吗？还是我应该仍然使用基础设施项目并在那里创建它们，以便我可以在其他项目中重用它？
不要过度设计您的解决方案，这些事情没有真正的对错。做最简单的事情来解决您的问题并提供功能。
所以最大的问题是，当您可以使用 SqlMembershipProvider 来实现相同的事情时，为什么要这样做（当然，除非您正在更改使用 aspnet_regsql 命令创建的表结构）
无论如何，抛开问题不谈，我倾向于遵循微软的命名空间约定。因此，在您的情况下，我将在您的解决方案中创建一个名为 YourCompany.Web.Security 的新类库，然后在名为 YourCompany.Web.Security.HibernateMembershipProvider 的命名空间中创建提供程序类。您所有的存储库和服务以及其他垃圾都将进入此程序集。
现在您遇到的更大问题是关于数据存储的学术问题。根据我的经验，最好不要将身份和“一般”配置文件数据与应用程序数据放在同一个数据库中。所以这个新的程序集应该检查你正在连接的数据库实例并创建表等来支持你的成员需求（假设你正在实现一个完整的提供者）
您可能还需要编写自己的 web/windows 应用程序来管理用户。
因此，当 SqlMembershipProvider 已经存在所有这些时，我真的会质疑您正在做的事情的价值。
说了这么多，对于调查 .net 4.5 的新 Microsoft Identity Foundation (WIF) 功能并使用 azure 管理您的身份数据，还有很多话要说。它很容易设置。
尽管我完全同意 Peter 和 Modika，但我想补充几点。
在设计您的应用程序时，您需要了解将这些内容放在单独项目中的原因，并对关注点分离有透彻的了解。意思是，你需要知道你在分离什么，为什么你会担心它。
我没有读过那本书，所以我对作者的方法没有评论。无论如何，在相信作者如何命名事物是“专业”的做法之前，停下来不仅要考虑您的应用程序，还要考虑诸如 .net 框架本身之类的事物的结构。
在任何给定的项目中，您可能必须生成几种类型的工件，包括：数据访问代码、对象模型、UI、业务逻辑等。
有几个自然边界区域。例如，您可能希望将数据访问代码分离出来，以防您需要换出永久存储选项，甚至只是换出使用 LINQ、NHibernate 或您拥有的访问方法等访问方法。
您可能希望在其他解决方案中重用对象模型的可能性；或者您甚至可能想要支持交换 UI 部分，例如从 WebForms 移动到 MVC 到任何东西。您甚至可能需要根据对象模型的使用方式或使用对象来将不同的业务逻辑应用于对象模型。
也就是说，并非每个应用程序都有相同的结构需求。例如，如果没有业务逻辑，对象模型可能完全没有意义；或者，更有可能的是，某些逻辑绝对必须与类定义合并，而其他逻辑则特定于库的使用方式。如果是前者，那么您有充分的理由将业务逻辑与类定义放在完全相同的项目/程序集中。如果是后者，那么您可能希望将其分离到其他程序集中并为对象实现接口定义。
根据我的经验，如果您不知道，请将其放在一起，因为这是最简单的选择，如果情况需要，可以在以后重构您想要的内容。
如果您在早期进行过度设计，那么您会增加项目时间/成本，从而获得可能永远无法实现的潜在收益；这很少是一个好的决定。还有一个问题是，你不知道以后可能需要什么，现在分离可能意味着你今天增加了项目时间，但以后仍然需要重构，这是双重打击。真正专业的开发人员恕我直言，在评估潜在解决方案时会考虑成本/开发时间。
现在，了解关于很有可能在其他项目中重用的定制会员提供程序的特定要求。自定义提供者应该在它自己的项目和命名空间中。我可能会使用像Company.Security. 这将提供最佳的可移植性方法，允许您仅重用相关代码，而无需拖累这个项目特有的各种其他东西。
因为它使用提供者模型，所以您的其他项目中不应该有需要直接引用这个的代码。只需使用已经存在的接口即可。