can you move the logic from the trigger into either the entity itself,
or an event listener on pre insert/update/delete?
in addition to that I would use the Post-Redirect-Get model when
issuing commands. Post for insert, update, delete, redirect to
complete the request (uow) and issue a query. for example a form is
submitted to create a new customer. a successful submit will display
the new customer.
(Monorail controller action)
public void Add(string customerName)
{
var id = session.Save(new Customer{Name = customerName});
RedirectToAction("ShowNewCustomer", new {id});
}
public void ShowNewCustomer(int id)
{
PropertyBag["Customer"] = session.Get<Customer>(id);
}
On Nov 12, 1:24 pm, Jason Grundy <[email protected]> wrote:
> In a web application that I inherited a database trigger is used to
> manage a column. An IHttpModule is being used to enforce the UoW. What
> I want to do is Save my entity and then detect the changes made by the
> trigger for re-display.
>
> From what I understand manually flushing the ISession is considered to
> be something of an anti-pattern (of course here I'd then I'd
> subsequently need to Evict and re-Get the Entity). There's certainly
> some type of CQS violation too and in fact the solution that I
> implemented was to redirect back to the View Action for the Entity
> (it's an MVC app).
>
> What would be the recommended approach here?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"nhusers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nhusers?hl=en
-~----------~----~----~----~------~----~------~--~---
