logo标签列表

使用Entity Framework作为数据访问层

.netasp.netentity-framework
13

在我的ASP.NET应用程序中，我想使用Entity Framework实现数据访问层，以便将其用作ORM工具。但我不希望应用程序的其他部分关注我正在使用的内容，也不希望受到任何特定于Entity Framework的污染。

我似乎找不到任何人在他们的数据访问层中完全使用Entity Framework，因此我很想看到任何在线示例或其他人的经验。

Stackoverflow的数据访问层：http://blog.stackoverflow.com/2008/09/what-was-stack-overflow-built-with/ - Ahmet Kakıcı
5个回答
4
4
3
2
建议的链接无法访问。 - Rafay
2
EF或者其他ORM（例如NHibernate）并不会取代数据访问层。相反，ORM是从DAL到数据源的抽象层。
不要被误导以为EF取消了DAL。EF只是另一个数据源框架。然而，在最佳实践中，您仍然需要在常见DAL中抽象和集中所有访问（读/写）。
以下是我想要说的完美例子。假设您必须在其中一个用例中删除给定用户。但是，在删除用户时，您可能希望删除与删除用户相关联的其他记录，以避免孤立的记录（老实说，我会为此使用存储过程）。现在，此用例卡在某个非常特定于此用例的BO中，删除用户仅是整个用例的一部分。
在某个时候，您可能会有一个开发人员被要求合并涉及删除用户的不同用例！开发人员可能会做几件事。1）他可能会创建一个新用例，现在涉及删除用户，但忘记删除与该用户关联的任何记录。2）他可能已经注意到之前的用例，但不能直接使用它，而不过于泛化它以适应他的用例，因此他决定将正确删除用户及其关联记录的先前用例的部分复制到自己的用例中。现在，我们有重复的代码部分，实际上做着相同的事情 - 删除用户。糟糕！现在，将此“删除用户”放入例如DAL.Users帮助程序类中，您可以避免这种不良的设计实践。
无论如何，EF的一个好处是它减少了我手动创建的业务实体数量，并为应用程序级别提供了与数据存储级别不同的数据视图。
2

我在最近的两个项目中都使用了Entity Framework作为数据访问。这些项目规模较大（至少对我来说），有几百个表，由5-15名开发人员持续超过一年。

在这两个项目中，我们将WCF接口引入了我们的服务层。我们不想在WCF合同中使用Entity Framework对象，因此我们创建了数据传输对象，并在DTO和Entity Framework对象之间进行映射。

这样可以分解依赖关系并尽可能地保持合同的稳定性，但也增加了一些额外的工作。

根据你的时间范围，我建议这样做，或者在下一个版本中使用POCO对象，正如Keith所提到的那样。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接