Gre*_*reg 15 c# entity-framework business-logic data-access-layer
在单独的数据访问和业务逻辑层中,我可以在业务层中使用Entity框架类吗？
编辑:我认为我将来不需要从我的业务逻辑中交换出数据访问层(即将是SQL Server),但是我将用于UI层.因此,问题更多的是在业务层中为我使用EF类有什么主要问题吗？好像管道代码会少一些.
mar*_*c_s 16
通常,"最佳实践"方法是这样的:
在您的数据层中,您有从实体加载并存储回数据库的EF实体
在您的业务层中,您有自己的域对象(只是简单的C#类),它们代表您的应用需要处理的数据.这些可以或多或少地与数据层实体相同,或者它们可以包含几个"原子"实体来构成业务对象,或者它们可以是非常不同的.为了减少对许多左手右手赋值语句的需求(在数据层实体和业务层对象之间来回移动属性值),你应该检查一下像AutoMapper这样的工具,它们很容易设置类似对象类型之间的"映射",允许您轻松地来回分配这些类型
然后,您的UI层将可视化并向用户表示业务层对象以获取信息和/或操作
好处是您的业务层域模型代表您正在使用的实际业务对象,并且或多或少地独立于这些对象实际存储在数据层中的方式.此外,这可以避免将UI层"粘合"到特定的数据访问技术.
当然 - 这是企业级应用程序的推荐最佳实践,您可能需要更换数据访问层等.对于更简单的应用程序,您可能会跳过这些实践,知道您在做什么,以及您是谁如果您通过业务层将EF实体一直使用到UI中,请将自己"锁定"到EF中.如果您和您的应用场景都没问题 - 没有特别的理由不这样做.EF实体是完全有效的.NET对象类 - 它们只是从一个公共基类派生而来(EntityObject而不是object)并且它们有一定数量的"包袱".但是没有什么可以阻止你在整个应用程序中使用这些EF实体.