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