Poco与ORM有什么"大"优势？

Question

我想到的一个优点是,如果你使用Poco类进行Orm映射,如果两者都支持Poco,你可以轻松地从一个ORM切换到另一个ORM.

拥有一个没有Poco支持的ORM,例如使用像DataObjects.Net Orm这样的属性进行映射对我来说不是问题,对于Poco支持的Orms及其生成的代理实体也是如此,你必须要知道实体实际上是绑定到某些上下文/会话的DAO对象,例如序列化是一个问题,等等.

Answer 1

POCO是松耦合和可测试性的全部.

因此,当您进行POCO时,您可以单独测试您的域模型(例如,如果您正在进行DDD).您不必担心它是如何持久存在的.您不需要存根上下文/会话来测试您的域.

另一个优点是泄漏抽象较少.因为持久性问题不会被推送到域层.所以你正在执行SRP原则.

我能看到的第三个好处是,POCO你的领域模型更具有进化性和灵活性.与添加到持久性相比,您可以更轻松地添加新功能.

我在使用DDD时使用POCO,但是对于某种应用程序,您不需要执行DDD(如果您正在执行基于小数据的应用程序),那么问题就不一样了.

希望这可以帮助

Answer 2

没有.点.人们喜欢扔的所有优点都是在图片的大规模上不重要的优点.我更喜欢实体对象的强基类,它实际上拥有大量集成代码(比如在属性更改时抛出属性更改事件),而不是自己编写所有这些内容.请注意,在"LINQ"或"ObjectSpaces"存在之前,我DID写了一个(当时是商用的)ORM for .NET.我已经使用了O/R mappers 15年了,从来没有发现POCO确实值得遇到麻烦的情况.

也就是说,属性可能因其他原因而变坏.我现在更喜欢Fluent NHibernate方法 - 使用属性启动了我自己的(现已退役的)映射器,然后转移到基于XML的文件.

"POCO让我一无所有"的主题主要来自实体简单而非正常的对象.它们具有许多额外的功能以及用户应该知道的限制(如查询速度等).ORM,尽管LINQ,但无论如何都不可替换 - 如果你开始使用他们真正有趣的更高功能的话.所以,最后你得到了POCO,仍然是一个基类和左右不同的语义.

我发现大多数POCO的支持者(如:"必须有",而不是"会很好")通常没有想到他们对真实目的的论证.你会得到各种非常糟糕的想法,几乎就是"存储过程比动态SQL更快" - 这些东西根本不适用.像:

• "我希望在他们不需要保存数据库的情况下使用它们"(使用单独的对象池,永不提交),
• "我可能希望在基类中拥有自己的功能(ORM应该将所有抽象实体归类为无功能,因此将您的OWN基类置于ORM之下)
• "我可能想要用另一个替换ORM"(所以永远不要使用任何更高的功能,希望ORM API兼容,然后你仍然可能需要重写大部分).

一般来说,POCO人员也忽视了实际工作量很大的工作量 - 如交易对象更新等等,基类中有一堆TON代码.某些.NET接口在POCO级别上实现起来很恐怖,但如果可以绑定到ORM则要容易得多.

在这里担任Thomas Jaskula的职位:

POCO是松耦合和可测试性的全部.

假设您可以在没有数据绑定的情况下测试数据绑定？可测试性是模拟框架的东西,并且真正有能力的甚至可以"重定向"方法调用.

因此,当您进行POCO时,您可以单独测试您的域模型(例如,如果您正在进行DDD).您不必担心它是如何持久存在的.您不需要存根上下文/会话来测试您的域.

其实不是真的.持久性应该是任何域模型测试的一部分,因为域模型是持久存在的.您总是可以通过不提交更改来测试非持久性方案,但是许多测试将涉及持久性和失败(例如,无效/丢失数据的发票无法写入光盘).

另一个优点是泄漏抽象较少.因为持久性问题不会被推送到域层.所以你正在执行SRP原则.

其实没有.适当的域模型永远不会在实体中具有持久性方法.这是一个以(user.Save())开头的垃圾ORM.OTOH基类将用于验证(IDataErrorInfo),处理持久字段上的属性更新事件,并且通常可以节省大量时间.

正如我之前所说,你应该拥有的一些功能实际上很难用变量作为数据存储来实现 - 比如将实体置于更新模式,进行一些更改然后回滚它们的能力.不需要 - 告诉微软谁在他们的数据网格中使用它(你可以改变一些属性,然后点击转义以回滚更改).

我能看到的第三个好处是,POCO你的领域模型更具有进化性和灵活性.与添加到持久性相比,您可以更轻松地添加新功能.

非说法.您无法在不处理持久性的情况下将字段添加到peristet类,并且可以将非持久性功能(方法)添加到非poco类,与poco类相同.

一般来说,我的非POCO基类做了以下事情:

• 处理属性更新和IDataErrorInfo - 无需用户为ORM可以处理的字段和项编写一行代码.
• 处理对象状态信息(新建,更新等).这是恕我直言的内在信息,也经常被推到用户界面.请注意,这不是"保存"方法,而只是EntityStatus属性.

它包含了许多可覆盖的方法,实体可以使用这些方法来扩展行为而不实现(公共)接口 - 因此这些方法对于实体来说是非常私有的.它还有一些内部属性,比如可以访问负责实体的"对象管理器",这也是要求其他实体(提交查询)的要点,有时需要这些实体.

Answer 3

在单一责任原则之后,POCO对ORM的支持就是关注点的分离.通过POCO支持,ORM可以直接与域模型通信,而无需使用特定于数据访问的代码"混淆"域.这可确保域模型旨在仅解决与域相关的问题,而不是数据访问问题.

除此之外,POCO支持可以更容易地隔离测试对象的行为,而无需数据库,映射信息甚至是对ORM程序集的引用.拥有"独立"对象的能力可以使开发变得更加容易,因为对象很容易实例化并且易于预测.

此外,由于POCO对象不依赖于数据源,因此无论是从主数据库,备用数据库,平面文件还是任何其他进程加载,都可以将它们视为相同.虽然这似乎不会立即有益,但无论来源如何对待对象都可以使行为易于预测和使用.

我为最近的ORM选择了NHibernate,因为它支持POCO对象,它处理得非常好.它适合项目遵循的领域驱动设计方法,并使数据库和域之间实现了很好的分离.

能够切换ORM工具并不是POCO支持的真正理由.尽管您的类可能与ORM没有任何直接依赖关系,但它们的行为和形状将受到ORM工具及其映射到的数据库的限制.更改ORM与更改数据库提供程序一样重要.一个ORM中总会有一些功能在另一个ORM中不可用,您的域类将反映功能的可用性或缺失.

在NHibernate中,您需要标记所有public或protected类成员virtual以启用对延迟加载的支持.此限制,虽然没有显著改变我的领域层,也有其设计的影响.