我是EF4的新手，之前没有任何经验。所以，如果这是一个非常简单的问题，请耐心等待。 我在BOL中有我的POCO实体（.tt文件），DAL中有.edmx文件（EDM），在Presentation层有我的webapp。所有业务逻辑都转到BLL层。 以下是参考资料：
UI - ＆GT; BLL-DAL-BOL
的 BLL - ＆GT; DAL-BOL
的 DAL - ＆GT; BOL
BOL - ＆gt;我的项目都没有。
1-我对图层区分的理解是否正确？我是朝着正确的方向吗？ 2-如何将ASP.NET成员资格提供程序与实体一起使用。我是否应该实现成员身份，持久性也无知并将sql server中的所有用户表映射到实体？
2-如何添加自定义验证？我不是指maxlength或有效的电子邮件......，我的意思是访问级别。例如，我希望某些用户能够在我的网站中修改字段（比如productprice）。我应该在哪里使用User.IsInRole方法？ BLL没有任何对用户信息的引用。我应该将一些参数传递给BLL（如“bool CanChangePrice”）来澄清访问级别吗？
答案 0 :(得分：6)
ProjectStructure
- 通常你的项目结构是正确的，你的参考是正确的。有些人可能会争辩说你想稍微分开你的顾虑并打破一些参考，但我个人认为你的结构是可行的。
作为一个实际问题，我倾向于将我的EDXM和POCO保留在同一个项目中。我只有一个Entities文件夹，其中包含EDXM和Model.Context.tt，一个用于Model.tt的POCO文件夹和我的Virtual POCO（下面），以及一个用于我的存储库的放大器文件夹。工作单位。
我还创建了一个名为VirtualPOCOs的文件，它是一个绑定到T4生成的POCO的部分类。我的设计往往与数据库结构紧密相关。 VirtualPOCO给了我一点灵活性，可以在这些一次性情况下偏离数据库设计。这里没有太多内容，只是每个项目似乎都有一些非常具体的需求。
您可能还需要考虑存储库，表数据网关或活动记录设置。所有这些模式都可能与工作单元相结合。有大量的设计模式，您的需求或偏好可能会将您推向一个或另一个。这里的要点是保护上层不直接访问EF4上下文。通过这种方式，您可以集中连接和事务管理并确保上层只使用POCO而不是意外地保留linq-to-sql对象。
会员提供者
MembershipProvider和EF之间肯定存在分歧。但是，您可以下载SQLMembershipProvider的源代码并将其转换为使用EF。我实际上做了这个转换。该文件长约1500行，但没有大量的ADO代码。
你没有问过什么，但我认为我应该解决的问题是，你是否想要使用会员提供者。如果您正在进行基本的会员管理和角色，那么会员，角色和配置文件提供商可以为您节省大量时间。有关功能的深入介绍，请查看4GuysFromRolla（http://www.4guysfromrolla.com/articles/120705-1.aspx）上的系列文章。
如果您的需求比较复杂，那么恕我直言，会员提供商会很快崩溃。例如，当用户注册您的站点时，您必须立即在少数几个不同的表中创建行。嗯，会员提供者通过webconfig注册并使用成员资格提供者界面。它只接受create函数中的某些字段。那么一个男孩要做什么？那么，您可以在控制器中打开更大规模的事务，运行成员资格提供程序添加用户函数，运行您自己的MyCustomUserStuff()，然后提交事务。我发现这个没有吸引力的两个原因是我现在让事务代码渗透到我的调用堆栈中，如果我需要做的就是添加一些额外的字段，我现在已经不必要地加倍了我的数据库调用。
我想我刚刚发现会员提供商非常有限，并且一旦进入并创建了我自己的自定义会员提供商，使用MS模型的好处很快就会消失。
验证
我认为这里的答案是响亮的 - 这取决于。您的权限是否相当静态？即那些“SiteManagers”组中的人可以在整个网站上进行编辑？或者你的权限更细粒度？这意味着SiteManagers可以访问分布在这22个表中的这75个字段，还是更基于表格？另外，权限有多可变？您的网站管理员是否需要能够频繁地打开/关闭访问不同表中的各个字段？
我想我需要更多地了解您对特定答案的要求。请记住，您获得权限的细粒度越多，客户端就越了解配置问题。管理所有权限。
另外，你使用的是什么后端？许多DBA都面临着这些决定。该世界中经常使用的策略是创建一系列视图，其中每个视图都公开用户拥有的列。例如，EmployeesHR视图将仅显示HR人员可以访问的列，EmployeeDirectory将仅显示该目录可访问的那些字段。然后HR用户被授予HR权限查看，但不是基础表。只是一个想法。
无论如何，希望这有帮助。
答案 1 :(得分：1)
1-你对这些层的区分对我来说是正确的。 我不会在UI中引用DAL，因为在我的项目中，我更喜欢只有中间层访问DAL。但这没错。 所以你似乎正朝着正确的方向前进。
2-据我所知，没有与EF合作的MembershipProvider 所以在我们使用会员资格的项目中，我们采取的是：
aspnet_regsql.exe Web.Config以使用SqlMembershiptProvider 在代码中，UserManager / RoleManager（BLL或DAL取决于您的体系结构）使用标准Membership方法获取信息。并始终使用Membership对象，而不是EF对象。实际上，用户/角色管理部分与EF分开。
当您的自定义表与Membership表之间存在链接时，我们仅使用aspnet_* EF实体（例如，当您要将表中的一个与aspnet_Users表链接以保持时插入数据的用户的引用。）
3-对于正确的管理，我会使用BLL RightManager，允许用户知道用户是否可以更改字段（因此您可以禁用它，或阻止输入），并使用此验证方法中的信息
在我的项目中，我使用Right表，并将权限与角色相关联。在RightManager中提供RequestRight(Right)方法
如果您的Right管理过于简单而无法创建表，请在RightManager中使用User.IsInRole（）（因此我会在BLL中使用它）。
如果它是“基本的”，我会将验证方法放在UI中，如果它包含更复杂的规则（例如涉及DAL访问），则将其置于BLL中。
答案 2 :(得分：0)
关于EF＆amp;籍 据我所知，您不需要使用任何数据库提供程序而不是成员资格提供程序 但如果您愿意，您可以在EF中映射成员资格表并创建其他方法 共同提供者