如何设计工作单元以支持批量操作并提高性能? [英] How to design unit of work to support bulk operations and give more performance?

问题描述

我有2个不同的工作单元:一个基于 ADO.NET ，主要调用存储过程(uowADO)，另一个使用 Entity Framework 6 (uowEF)，最近添加以支持 Oracle 数据库，这样我就不必重写所有SP(我的知识仅限于此).

I have 2 different units of work: one based on ADO.NET, calling stored procedures mostly (uowADO) and another one using Entity Framework 6 (uowEF), added recently in order to support Oracle db, so that I don't have to rewrite all the SPs (my knowledge is limited there).

因此，在对数据库执行操作时，业务层仅加载其中一个(基于配置)(但是我不能并行使用它们，因为uowADO不支持Oracle)

So, business layer is loading only one of them (based on configuration) when performing operations over database (but I can't use them in parallel, because uowADO does not support Oracle)

添加新的uowEF之后，我注意到了很大的性能问题，当然主要是在批量操作上.

After adding the new uowEF I noticed big performance issues, of course mainly on the bulk operations.

基本上，目前我在当前的IUnitOfWork上仅具有Commit和Rollback方法...非常接近于文章.

Basically I have only Commit and Rollback methods on the current IUnitOfWork for now... very close to what this article recommends.

因此，我正在考虑对这一工作单元进行返工.例如，我读到有关有时在涉及批量操作时禁用dbContext.Configuration.AutoDetectChangesEnabled的信息，以及有关 EF 的其他优化技巧的信息，这些信息可能会有所帮助.

So, I am thinking to rework this unit of work. For example, I read about disabling dbContext.Configuration.AutoDetectChangesEnabled sometimes when bulk operations are involved, and other such optimization tips regarding EF which may help.

不幸的是，我不确定如何设计这样的工作单元以使其通用，这样我就可以在BL和所有数据访问层的所有情况下都使用它: ADO.NET 和 EF .

Unfortunately I am not sure how to design such Unit of Work to make it generic so that I could use it in all cases from BL and for both data access layers: ADO.NET and EF.

对此有任何想法，建议和良好链接吗?

Any thoughts, recommendations, good links on this?

推荐答案

没有明确的答案.始终是灵活性和性能之间的折衷.所有这些模式(存储库，工作单元)都有利于灵活性，但不利于性能，因为具体的实现通常需要进行一些调整才能提供最大的性能，并且这些调整可能(实际上不会)与通用接口兼容.您可以调整接口，但是它可能无法与其他实现一起使用.所有这些ORM都非常不同，并且很难(几乎不可能)实现通用存储库/UOF接口来支持所有这些，特别是如果您具有ADO(低级ORM，实际上很难称其为ORM)和EF(高级别的ORM).将AutoDetectChangesEnabled设置为false只是使用EF的一小部分.为了从中获得更多性能，您还必须以特定方式实现实体(添加一些属性，一些属性).如果我们看一下Linq2Sql(另一个ORM)，它需要编译的查询，因此，请忽略这样的方法:

There are no clear answer. It is always the compromise between flexibility and performance. All these patterns (repository, unit of work) are good for flexibility, but not for performance as concrete implementations ussually require some tweaks to provide maximum performance and these tweaks may not (actually they will not) be compatible with the generic interface. You can adapt the interface, but it may not work with other implementations. All these ORMs are very different ant it is very hard (almost impossible) to implement generic repository/UOF interface to support all of them, especially if you have ADO (low level ORM, actually it is difficult to call it ORM) and EF (high level ORM). Setting the AutoDetectChangesEnabled to false is just a small part of what you can do with EF. To get more performance from it, you also have to implement enities in a specific way (add some properties, some attributes). If we look at Linq2Sql (another ORM), it requires compiled queries, so, forget about methods like this:

T Single(Expression<Func<T, bool>>  predicate);

在您的存储库中

.我只是在谈论关系数据库的存储库.那NoSql数据库的存储库又如何呢?基于完全不同的数据源的存储库又如何呢?是的，可以为泛型接口提供泛型逻辑，但是对于某些数据源来说这将非常慢.如果您真的想实现通用解决方案并获得最大的性能，那么您用于UOF的存储库应该具有非常特定的界面，例如:

in your repositories. And I'm just talking about repositories for relational databases. What about repositories for NoSql databases? What about repositories based on completely different data sources? Yes, it is possible to provide generic interface with generic logic, but it would be very slow for some data sources. If you really want to implement generic solution and get maximum perfomance, your repositories for UOF should have very specific interface like:

IEnumerable<T> GetStudentsByName(srting name)

void InsertStudents<T>(IEnumerable<T> students)

其中T-不依赖具体存储库实现的业务级别实体.存储库应负责将T转换为实现访问的ORM的实体acceptabe.但是请记住，解决方案将过于复杂且难以支持.

where T - business level entities which should not depend on concrete repository implementation. The repositories should be responsible for converting the T into entities acceptabe for ORM it implements access to. But keep in mind that solution will be too complex and hard supportable.

如果我是您，我会选择一个最适合我的需求的主ORM，并围绕该ORM设计存储库，以从中获得最大的性能.但是，我将使接口足够灵活，以使其有可能至少实现对其他数据源或ORM的缓慢(但有效)访问.

If I was you, I would choose one main ORM which fits my requirements best and would design repositories around this ORM to get maximum perfromance from it. But, I will keep the interface flexible enough to have possibility to implement at least slow (but working) access to other data sources or ORMs.

这篇关于如何设计工作单元以支持批量操作并提高性能?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！