Why is MvcTransactionFilter related to SchoolContext ?

[akarzazi]

MvcTransactionFilter works only for SchoolContext.

 public class MvcTransactionFilter : ActionFilterAttribute
    {
        public override void OnActionExecuting(ActionExecutingContext filterContext)
        {
            // Logger.Instance.Verbose("MvcTransactionFilter::OnActionExecuting");
            var context = StructuremapMvc.ParentScope.CurrentNestedContainer.GetInstance<SchoolContext>();
            context.BeginTransaction();
        }

    ...
}

Is there a way to make MvcTransactionFilter work for multiple datacontexts ? By the way the multiple contexts may want to share the same transaction scope.

[jbogard]

Do you have a better option? I don't really have your situation.

On Monday, October 24, 2016, akarzazi notifications@github.com wrote:

MvcTransactionFilter works only for SchoolContext.

public class MvcTransactionFilter : ActionFilterAttribute { public override void OnActionExecuting(ActionExecutingContext filterContext) { // Logger.Instance.Verbose("MvcTransactionFilter::OnActionExecuting"); var context = StructuremapMvc.ParentScope.CurrentNestedContainer.GetInstance(); context.BeginTransaction(); }

...

}

Is there a way to make MvcTransactionFilter work for multiple datacontexts ? By the way the multiple contexts may want to share the same transaction scope.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jbogard/ContosoUniversity/issues/31, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGYMqK0DRMWACg9qJZtRby8tLdqT2FSks5q3TITgaJpZM4KfXEm .

[akarzazi]

The name "MvcTransactionFilter" is misleading ( and somewhat a lie :) ) The real name is "MvcSchoolContextTransactionFilter".

Actually, I came here looking for the "supposed" better approach ^^.

Did you use this approach in real apps ? Therefore those apps do have a single context ?

[jbogard]

Ok......in general I don't try to implement a single approach that works for every situation. I rely on my teams to understand their specific situation and adapt an approach as needed.

And yes, my apps have a single DbContext. Single DB, single context. If my apps are talking to multiple DBs, I have a different problem.

If you need an ambient transaction, you can also do a System.Transactions transaction. But not all my apps need it. So I'm not interested in creating the One Transaction Filter To Rule Them All. I have an approach, a filter that manages transactions, and then adapt as necessary.

[akarzazi]

Indeed, the preferred solution would be a business ambient transaction that is assigned automatically to injected Dbcontexts and that could be injected as a dependency for a use in something else than EF.

If the positioning of a beginTransaction is quite simple, the commitTransaction timing is more complicated. As some actions like "email notification" would need to ensure that the transaction has successfully completed before firing.

[jbogard]

OK, lemme know what you come up with!