How to design unit of work to support bulk operations and give more performance?

Question

I have 2 different units of work: one based on ADO.NET, calling stored procedures mostly (uowADO) and another one using Entity Framework 6 (

Answer 1

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>  predicate);

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 GetStudentsByName(srting name)

void InsertStudents(IEnumerable students)

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.

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.