Quantcast
Channel: URF - Unit of Work & (extensible/generic) Repositories Framework
Viewing all articles
Browse latest Browse all 1539

New Post: Use Case: gradual integration of Repository.Pattern with existing applications

$
0
0

Scenario

The business has a large set of applications that would like to adopt the Repository.Pattern approach over time. The challenges are:
  • many shared libraries between applications that will need testing written to ensure correct adoption, but can be updated over time
  • libraries from external vendors that are hard to update/not possible to update
  • not wishing to disrupt the normal (high tempo) release cycle that includes other feature requests and bug fixes
The main blocker to adoption is:
  • Service layers in external libraries take an injected DbContext can resolve Set<TEntity> on the context (leaving the correctness of that aside, this does exist) and call DbContext.Save.
  • However this will not save to the database as they do not know about IObjectContext when they create the entity. Therefore when the DataContext overrides for SaveChanges kick in, they will set the EF entity state to Unmodified
  • For a fake example see Northwind.Test.IntegrationTests.UnitOfWork_Tests_ChangeTracking.InsertWithoutChangeOverrideFails() in GenericUnitOfWorkABContrib 6d6578e5

Proposed Solution

  • Each of these external service operations (due to the nature of the EF DbContext.SaveChanges method) can be viewed as "atomic" within the larger transaction controlled by UoW as they terminate with a SaveChanges call
  • Therefore provide the ability to "turn off" the Repository.Pattern's "conforming interface" for change tracking and let EF take over, either for entire UnitOfWork scopes, or for one-off EF-only operations performed by external services.
Initially this would let an adopter change the DbContext subtype to a DataContext subtype, but set the change tracking mode to let EF control change tracking as before. Services can then be upgraded individually by specifying the default Repository.Pattern change tracking as the default, and deal with Special Case exceptions using a temporary scope. Eventually the Repository.Pattern change tracking can be adopted as the norm, at which point the framework will have been completely integrated.

Request For Comment

Proof of concept code has been committed for comment (I am still testing it) in the branch GenericUnitOfWorkABContrib dev-cr-integration (inclusive of) from GenericUnitOfWorkABContrib 7157b4c4e30f to 06f4d37a419e.

Examples of setting the mode, or creating temporary scopes are in Northwind.Test.IntegrationTests.UnitOfWork_Tests_ChangeTracking

Viewing all articles
Browse latest Browse all 1539

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>