Why is MvcTransactionFilter related to SchoolContext ?
akarzazi opened this issue · 5 comments
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.
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
#31, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AAGYMqK0DRMWACg9qJZtRby8tLdqT2FSks5q3TITgaJpZM4KfXEm
.
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 ?
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.
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.
OK, lemme know what you come up with!