实体框架POCO实体在多层web应用程序

Question

我是EF4的新手，并没有任何使用经验。所以，如果这是一个非常简单的问题，那么我就不会。 我有BOL中的POCO实体（.tt文件），DAL中的.edmx文件（EDM）和Presentation层中的webapp。所有的业务逻辑都转到BLL层。 下面是引用：

UI - > BLL-DAL-BOL
BLL - > DAL-BOL
DAL - > BOL
BOL - >无我的项目。

1-我对图层区分的理解是否正确？我在正确的方向吗？ 2-我如何使用ASP.NET Membership Provider与实体。我是否应该实现成员资格，持久性也是无知的，并将sql server中的所有用户表映射到实体？

2-如何添加自定义验证？我不是指maxlength或有效的电子邮件...，我的意思是类似访问级别。例如，我希望某些用户能够在我的网站中修改一个字段（比如productprice）。我应该在哪里使用User.IsInRole方法？ BLL没有任何对用户信息的引用。我应该将一些参数传递给BLL（例如“bool CanChangePrice”）以澄清访问级别吗？

Answer 1

Wow Kamyar，这个问题中包含的几个问题;-)我不知道是否我会覆盖所有可能的基础，但是这里有。

ProjectStructure
- 通常你的项目结构是正确的，你必须引用是正确的。有些人可能会争辩说，你想分开你的关注点，并打破一些参考文献，但我个人认为你的结构是可行的。

• 作为一个实际问题，我倾向于将我的EDXM和POCO保持在同一个项目中。我只有一个Entity文件夹，其中包含EDXM和Model.Context.tt，Model.tt的POCO文件夹和我的虚拟POCO（下），以及用于我的存储库&工作单元的Repository文件夹。

• 我还创建了一个名为VirtualPOCOs的文件witch是一个绑定到由T4生成的POCO的部分类。我的设计倾向于与数据库结构紧密相连。在这种一次性的情况下，VirtualPOCO给了我一点灵活性来偏离DB设计。这里没有多少东西，只是每个项目似乎都有一些非常特殊的需求。

• 您可能还需要考虑存储库，表格数据网关或活动记录设置。所有这些模式都可能与工作单元结合在一起。有大量的设计模式，你的需求或喜好可能会推动你到另一个。这里的要点是屏蔽上层直接访问EF4上下文。通过这种方式，您可以集中连接事务管理，并确保上层仅使用POCO，而不会意外地持有linq-to-sql对象。

成员资格提供
还有就是和的MembershipProvider EF之间的绝对是一个分裂。但是，您可以下载SQLMembershipProvider的源代码并将其转换为使用EF。我其实做了这个转换。该文件长约1500行，但没有大量的ADO代码。

你没问过，但我想我应该说的是，你是否想使用Membership提供者。如果您正在进行基本的会员管理和角色，那么会员，角色和配置文件提供者可以为您节省大量时间。要深入了解功能，请查看4GuysFromRolla（http://www.4guysfromrolla.com/articles/120705-1.aspx）上的系列文章。

如果您的需求比较复杂，那么恕我直言，会员提供商很快就会崩溃。例如，当用户注册您的网站时，您必须立即在少量不同的表格中创建行。那么，成员资格提供者通过webconfig注册并使用成员资格提供者接口。它只接受create函数中的某些字段。那么，男孩应该做什么？那么，您可以在控制器中打开更大规模的交易，运行会员供应商添加用户功能，运行您自己的MyCustomUserStuff()，然后提交交易。我觉得这两个原因没有吸引力的两个原因是，现在我的事务代码已经渗透到我的调用堆栈中，如果我只需要添加一些额外的字段，我现在已经无需将数据库调用加倍。

我想我刚刚发现会员提供商相当有限，一旦进入并制作我自己的自定义会员提供商，使用MS模型的好处很快就会消失。

验证
我认为这里的答案是一个响亮的 - 它取决于。你的权限是否相当静态？即“SiteManagers”组中的那些人可以在整个网站上进行编辑？或者你的权限更加细化？含义SiteManagers可以访问分布在这22个表格中的这75个字段，还是更基于表格？另外，权限有多可变？您的网站管理员是否需要频繁开启/关闭访问权限或关闭不同表格中的各个字段？

我想我需要听取更多关于您对特定答案的要求。请记住，如果您的权限越精细，则配置头疼越多，客户端将理解&管理所有权限。

此外，您使用什么后端？许多DBA面临这些决定。在这个世界中经常使用的策略是创建一系列视图，其中每个视图暴露用户拥有的列。例如，EmployeesHR视图只会公开HR人员可以访问的那些列，而EmployeeDirectory会公开那些目录有权访问的字段。然后人力资源用户被授予人力资源视图的许可，但不允许基础表。只是一个想法。

无论如何，希望这有助于。

Answer 2

1-你对图层的区分对我来说似乎是正确的。 我不会在用户界面中引用DAL，因为在我的项目中，我更喜欢只有中间层访问DAL。但这并没有错。 所以你似乎在正确的方向。

2-据我所知，没有与EF一起使用的MembershipProvider。
所以在这里我们使用的会员项目，这里是我们所做的事情：

• 创建的表与aspnet_regsql.exe
• 配置Web.Config使用SqlMembershiptProvider
• 在web.config另一个连接字符串添加（一个用于会员，另一个用于EF）
• 构建EDMX文件包含所有表格，包括Membership。

在代码中，一个UserManager/RoleManager（BLL或DAL这取决于你的架构）获得使用标准的成员方法的信息。并且总是使用Membership对象，而不是EF对象。所以实际上用户/角色管理部分与EF分开。

当您的自定义表格和成员资格表格之间存在关联时，我们只使用aspnet_* EF实体（例如，当您想将表格中的一个与aspnet_Users表格连接起来以保留插入的用户的参考一个数据）。

3-对于正确的管理，我会使用BLL RightManager，这将允许用户界面知道用户是否可以更改该字段（以便您可以禁用它或防止输入），并在您的验证方法。
在我的项目中，我使用了一个Right表，我将权利与角色关联起来。在RightManager提供RequestRight(Right)方法。
如果您的权限管理过于简单而无法创建表格，只需在您的RightManager（因此我将在BLL中使用它）中使用User.IsInRole（）。
如果验证方法是“基本”的，我会把验证方法放在用户界面中，如果它包含更复杂的规则（例如涉及DAL访问），那么在BLL中。

Answer 3

约EF &会员 我所知，你不需要使用任何DB提供程序而不是成员提供 ，但如果你愿意，你可以映射在EF成员表，并创造更多的方法来 公共供应者