|
前言
首先抛出一个问题,在XAF项目中,我们现在可不可以选择EFCore?每个人可能都有自己的答案,这也没有什么标准答案。下面是我的个人看法,在刚接触XAF时,如何选择ORM,我也是犹豫了许久,最终选择了XPO,主要基于以下几点考虑
1.XPO是DEV的产品,支持力度及倾向性要比EFCore高
2.XPO是XAF最开始支持的ORM,XAF中的各个模块对XPO的支持更好(有个别模块不支持EFCore)
3.在XAF的社区中,关于XPO的各个方面的问题都有相应的解答,相对来说比EFCore更有优势
我想应该也有部分小伙伴可能与我的考虑是一致的,但为啥要抛出这个问题呢,是因为XAF的一篇文章(https://docs.devexpress.com/eXpressAppFramework/404186/why-we-recommend-ef-core-over-xpo)
DEV建议在新的XAF项目中优先采用EFCore,文章中对比了XPO与EFCore,总体来说它们各有特点,也有很多相似之处。DEV建议优先选择EFCore的原因可能与XPO一直处于维护状态有关,此外,EFCore的发展势头也越来越强劲,在XAF中使用EFCore已成为大势所趋。但是将XPO迁移到EFCore并不容易,由于XAF最初的ORM是XPO,因此某些功能是基于XPO或倾向于XPO,所以在EFCore上的效果可能会有所不同。
探讨
虽然XPO和EFCore在语法上有许多不同,但在思想上基本一致。大部分XPO中的特性都被EFCore支持,但是有一个EFCore没有的特性,即NestedUnitOfWork,在EFCore中对应NestedDbContext,但EFCore没有。XAF利用XPO的这个特性构建了XPNestedObjectSpace,使父子表(或主从表)之间的操作更加自然和灵活。
由于EFCore没有这个特性,因此使用起来与XPO的操作不一致,甚至会给人一种不可接受的感觉。下面通过刨析它们内部的原理,来讲解它们行为不一致的原因,同时不可接受的地方,通过了解后是否可以接受它。
首先讲一下,在XPO中习以为常的功能,在EFCore中却会出现不一样的行为。这主要出现在父子表中,或者说聚合实体中,这里假设一个场景,用户表(User)中包含一个用户标记(UserTag)列表(Tags),它是聚合的(Aggregated),这是一个一对多的关系。当我们新建User后,再向Tags列表中添加UserTag时,在EFCore下,会自动保存User,而在XPO中不会有这样的操作,这样会造成一个问题,如果此时,我想放弃当前新建的User,我把User关闭后,列表中会多一条刚才放弃的User,这种现象在XPO中是没有的,为什么会有这样不一致的行为呢。这就是前面提到的XPNestedObjectSpace,而EFCore没有这样的一个实现。
这里要引出XPO中的Session,它与EFCore的DbContext是对应的(确切的说与UnitOfWork更像),Session有多个子类如UnitOfWork,NestedUnitOfWork,ExplicitUnitOfWork,通过名称我们也可以了解它们的用途,我们平时在创建BO类时,都要有一个包含Session参数的构造函数,这里的Session一般都是它的子类UnitOfWork,Session中的事务比较简单,我们在调用BO对象中的Save方法时,就会直接提交到数据库。UnitOfWork又多了一层,调用BO对象中的Save方法时,并不会立即提交到数据库,我们需要调用UnitOfWork中的CommitChanges方法,它会将工作单元中的BO对象一并提交到数据库,而ExplicitUnitOfWork会启用一个显式事务(也称作数据库级事务),我们通过BeginTransaction方法开启事务,通过CommitTransaction方法提交事务,在没有提交之前,你可以多次调用CommitChanges方法,如果其中一个提交出现异常或其它原因放弃提交,你可以通过RollbackTransaction方法回滚事务,这样就可以将之前的所有提交都进行回滚。
NestedUnitOfWork是我们需要重点关注的,它就是嵌套工作单元,你也可以把它看作是UnitOfWork的子工作单元,它有一个好处就是,它可以直接访问到父级中的对象也就UnitOfWork中的对象,同时它提交时,并不会直接提交到数据库,而是等待父级的UnitOfWork一起提交,它们的提交是放在同一事务中的,如果NestedUnitOfWork不提交,而父级UnitOfWork进行了提交,此时提交的内容不会包含NestedUnitOfWork中的对象。
以上NestedUnitOfWork的特点带来许多好处,如可以使父子表间的编辑变的简单,父表提交时,可以一起提交子表,父表放弃后,子表也会放弃,子表也可以随时单独放弃等等,当与XAF的主从视图结合时,就会有很不错的操作体验。
如果没有NestedUnitOfWork,将会发生什么呢,首先两个UnitOfWork是不能直接通信的,其中一个UnitOfWork创建的对象,如果另一个UnitOfWork想访问,第一个UnitOfWork需要先提交到数据库,第二个UnitOfWork再从数据库中读取,而NestedUnitOfWork可以直接通过GetObject方法访问到父级UnitOfWork中的对象,这样就减少了一次提交与读取的过程。
再回到前面创建User的示例,由于UserTag与User是聚合关系,也就是UserTag只属于一个User,同时UserTag中的User外键还不能为空,也就是说UserTag脱离User,它本身就没有意义,相当于订单与订单明细的关系。在这种情况下,我们在User中新增UserTag时,UserTag首先需要一个User,而如果此时User也是新建的,并且它们分别在不同的UnitOfWork中时(在XAF的主从视图中,如果新建从表数据,XAF会单独创建一个ObjectSpace,也就是当前User与UserTag会在不同的ObjectSpace中),我们能想到的就是保存User,在UserTag所在的UnitOfWork中从数据库中读取User。
看到这里的小伙伴应该明白了,XAF为什么会在新增UserTag时需要保存User了吧。我们刚才谈到的是聚合关系,如果不是聚合的一对多关系是否会自动保存父级呢,不会的,因为不是聚合,那它的外键可以为空,也就是UserTag的User外键可以为空,这样在新建时,可以不必事先获取父级,那也就没必要保存父级了。
前面讲的都是新建的User,如果是已存在的User,也就是从列表中打开的User,如果在User中新增UserTag会不会自动保存呢,也不会,因为User已存在于数据库中,在UserTag的UnitOfWork中就可以从数据库中获取到User,这样也没有必要保存User。如果仔细观察,在没有修改User的情况下,新增UserTag,保存按钮还是处于禁用状态,这是由于它们处在不同的UnitOfWork中互不干扰。
在EFCore中,将上面的UnitOfWork替换为DbContext,也就知道了为什么EFCore会出现与XPO不一致的行为了,这里的关键点就是NestedUnitOfWork,而EFCore没有对应的实现,那是不是EFCore就不是一个好的选择呢,我倒觉得不是,通过上面的示例,我们可以看到,除了在新建具有聚合关系的对象时,会出现与XPO不一致的行为,其它的地方与XPO基本保持一致。
随手创建,随手放弃,可能是我们日常测试时经常操作的,但是在上线运行时,日常操作会有相关的约束,不会频繁出现这样的行为,再加上XAF自动保存时也会进行数据校验,校验不通过也是无法进行自动保存的,同时由于Blazor自身的特点,对于一些需要长时间录入的页面,我们还需要自己加入自动保存的功能,已防止录入数据的丢失。
我曾经试图去解决这个问题,为EFCore创建一个EFCoreNestedObjectSpace,EFCoreNestedObjectSpace直接采用父级的DbContext,这样可以实现在一个事务中提交,但最后发现解决一个问题,引出一堆问题,最后还是放弃了,在底层没有支持的情况下,是无法实现与XPO相似效果的。
在了解了上面的内容后,我们发现,XAF中使用EFCore,与XPO相比出现的不一致行为,也不这么神秘了。但这不是全部,EFCore与XPO还是有很多不同的,如果习惯了XPO,你会发现在XPO中有许多默认行为,在EFCore中需要手动的配置,比如延迟删除、乐观并发等,这些需要注意。
关于XPO中的延迟删除(DeferredDeletionAttribute),有些小伙伴会把它当成软删除(SoftDelete),这是不正确的,它与软删除还是不一样的,虽然延迟删除不会删除记录,但它会清除记录中的外键,它的存在是为了解决XPO删除记录时,由于数据库的外键约束造成的失败,但本质还是删除,只是保留了记录,事后需要自己清理。当你试图恢复延迟删除的记录,你会发现记录与其它记录的关系没有了,这也是为什么不能用作软删除的原因。EFCore中实现软删除比较简单,使用HasQueryFilter配置实体就能实现软删除的功能,事后我会在XAF中实现一个EFCore版的软删除分享给大家。
最后
随着XAF中使用EFCore的深入,可能还会发现与XPO的不同,或出现一些无法解决的问题,我都会更新到文章中。当我完全切换到EFCore时,可能今后就要远离XPO了,有些不舍,但总要去面对,新技术总会取代旧的技术。
https://www.cnblogs.com/haoxj/p/17416380.html
来源:https://www.cnblogs.com/haoxj/archive/2023/05/20/17416380.html
免责声明:由于采集信息均来自互联网,如果侵犯了您的权益,请联系我们【E-Mail:cb@itdo.tech】 我们会及时删除侵权内容,谢谢合作! |
|