Recommended approach for refreshing an Entity post-save

[Jason Grundy]

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?

[Jason Meckley]

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

[Jason Grundy]

Thanks for the reply Jason M. I appreciate that there are alternatives
to a trigger within NHibernate but, for the sake of this discussion,
can we just assume that the trigger is something that can not be
changed?

The "Post-Redirect-Get" approach that you outline does not violate CQS
and that is actually what I am doing. I was simply wondering whether
within a single UoW there is an alternative to the Flush-Evit-Get
triumvirate?

[Jason Meckley]

I know there is a option to always select before update. maybe one
exists for always select after save. if so i would set this in the
mapping. this way you don't need to think about it in your domain.
this would happen every time you commit a modification to the entity
so you need to consider that.

you may also be able to use a postinsert and postupdate event listener
(maybe after commit transaction would be better). verify the typeof
entity and evict/get from session. this keeps the functionality in the
infrastructure so the domain remains clean.