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

问题描述

在单独的数据访问和放大器; ？业务逻辑层，我可以使用实体框架类在业务层

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

编辑：我不认为我需要从我的业务逻辑换出数据访问层在未来的（如将SQL Server）的，但我会为UI层。因此，问题是更意味着是有没有在业务层使用EF类对我有什么重大问题？ 。好像会有更少的管道代码

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:

<在你的数据层LI>

，你有获得来自加载并存储到数据库中EF实​​体

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

在业务层，你有自己的域对象（只是普通的C＃类），这表示您的应用程序需要工作的数据。这些可以是或多或少相同数据层实体，或它们可以包含多个原子的实体，以弥补业务对象，也可以是完全不同的。为了减轻对很多左手右手赋值语句（移动属性值来回数据层实体和业务层对象之间）的需要，你应该看看喜欢的AutoMapper ，使得它非常容易建立类似的对象类型之间的映射，让你轻松地分配这些类型来回

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

你的UI层（S），然后将可视化和表示业务层对象给用户的信息和/或操纵

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

这样做的好处是，你的业务层域模型代表实际的业务对象与您合作，并成为或多或少的独立的如何将这些真正存储在数据层。 。另外，这样就避免了胶合你的UI层到一个特定的数据访问技术。

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.

当然 - 这是一个企业级的应用程序，你可能会在建议的最佳实践需要换出数据访问层等。对于一个简单的应用程序，你可以跳过这些做法的知道的你在做什么，你是锁定自己成为EF如果你使用EF实体一路通过业务层到UI。如果这是确定你和你的应用场景 - 有没有特别的理由不这样做。 EF实体是完全有效的.NET对象类的 - 他们只是从一个公共基类派生（ EntityObject 而不是对象）他们有一定的走来包袱的。但没有什么利用这些EF实体的所有在您的应用程序阻止你。

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.

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