在单独的数据访问业务逻辑层，我可以在业务层使用Entity框架类吗？ [英] In separate data access & business logic layer, can I use Entity framework classes in business layer?

问题描述

在单独的数据访问&业务逻辑层，我可以在业务层使用Entity框架类吗？

编辑：我不认为我需要从我的业务逻辑中交换数据访问层在将来（即将是SQL Server），但是我将为UI层。因此，问题更多的是在业务层使用EF类有什么重大问题？似乎会有更少的管道代码。

解决方案

通常，最佳实践的方法将是这样的：您的数据层中有

• ，您的EF实体将从数据库加载并存储回

您的业​​务层中有


• ，您有自己的域对象（简单的C＃类），代表应用程序需要处理的数据。那些可以或多或少地与数据层实体相同，或者它们可以包含几个原子实体来构成业务对象，或者它们可以是非常大的差异。为了减轻对大量左手右手分配语句（在数据层实体和业务层对象之间来回移动属性值）的需要，您应该查看一些工具，如 AutoMapper ，这样可以很容易地在类似的对象类型之间设置映射，并允许您轻松地来回分配这些类型。




• 然后，您的UI层将可视化并将业务层对象表示给用户以获取信息和/或操纵。

好处是，您的业务层域模型表示您正在使用的实际业务对象，并且变得或多或少地独立于数据层中真正存储的方式。此外，这避免了将您的UI层粘贴到特定的数据访问技术。

当然 - 这是企业级应用程序的推荐最佳做法，您可以在其中需要更换数据访问层等。对于一个更简单的应用程序，您可能会跳过这些做法，了解您正在做什么，如果您使用EF，您将锁定到EF中实体一直通过业务层进入UI。如果你和你的应用场景是可以的 - 没有任何特别的理由不这样做。 EF实体是完全有效的.NET对象类 - 它们只是从公共基类（ EntityObject 而不是对象）派生出来他们有一定数量的行李。但是，您的应用程序中没有任何东西阻止您使用这些EF实体。

In separate data access & business logic layer, can I use Entity framework classes in business layer?

EDIT: I don't think I will need to swap out the data access layer from my business logic in the future (i.e. will be SQL Server), however I will for the UI layer. Therefore the question is more meant to be are there any major issues with using EF classes for me in the business layer? Seems like there would be less plumbing code.

解决方案

Typically, the "best practice" approach would be something like this:

• in your Data layer, you have EF entities that get loaded from and stored back to the database

• in your Business layer, you have your own domain objects (just plain C# classes) that represent the data that your app needs to work on. Those can be more or less identical to a data layer entity, or they can contain several "atomic" entities to make up a business object, or they can be vastly different. To alleviate the need for a lot of left-hand-right-hand-assignment statements (to move property values back and forth between data layer entities and business layer objects), you should check out tools like AutoMapper that make it really easy to set up "mappings" between similar object types and allow you to easily assign those types back and forth

• your UI layer(s) will then visualize and represent Business layer objects to the user for information and/or manipulation

The benefit is that your business layer domain model represents the actual business objects you're working with, and becomes more or less independent of how those are really stored in the data layer. Also, this avoids "glueing" your UI layer to a particular data access technology.

Of course - that's the recommended best practice for an enterprise-scale app, where you might need to swap out the data access layer etc. For a simpler app, you might skip those practices, knowing what you're doing, and that you're "locking" yourself into EF if you use EF entities all the way up through the business layer into the UI. If that's ok with you and your app scenario - there's no particular reason not to do it. EF entities are perfectly valid .NET object classes - they simply derive from a common base class (EntityObject instead of object) and they have a certain amount of "baggage" that comes along. But there's nothing stopping you from using those EF entities all throughout your app.

这篇关于在单独的数据访问业务逻辑层，我可以在业务层使用Entity框架类吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！