2012/8/7 Philip Mateescu <[email protected]>
> 2. Restore complex properties performing lookups:
> *var user = Repository.FindRepo<User>().GetById(dto.UserId);*
> if (user != null) entity.Buyer = user;
>
Sounds crazy unless you ONLY do it when the dto.UserId indicates a
different user than the one already present in the entity.Buyer. I.e.
if (entity.Buyer == null || entity.Buery.Id != dto.UserId)
...GetById();
>
> 3. Validate DO
> 4. Save DO.
> Repository.FindRepo<MyEntity>.AddOrUpdate(entity);
>
What you describe above sounds like a single unit-of-work, and should thus
take place inside a single transaction. If so, calling SaveOrUpdate() is
ONLY required (and useful) for entirely new object. Objects loaded from
NHibernate are already tracked by the session.
>
> I'm running into problems on Step #2 because GetById() is implemented
> something like this, on recommendation that Gets are within their own
> transactions (so that they benefit from L2 cache):
>
using (var tx = Session.BeginTransaction()) {
> result = Session.Get<T>(id);
> tx.Commit();
> }
>
>
Sounds crazy! Your entire unit-of-work should be a single transaction (very
common pattern). If you chop your work into several pieces spread over
multiple transaction, you have nullified the benefits of using transactions
(i.e. all-or-nothing).
> Are we supposed to open up a transaction before Step #0, execute
> everything in that transaction - then Commit or Rollback depending on
> validation result?
>
>
Yes!
> Is there another pattern you would recommend?
>
"Open Session In View" is very common. "Open/Close Transaction in
Repository" is an anti-pattern.
/Oskar
--
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.
