> Entities - Objects NH maps to > EntityManagers - Business objects that perform actions on the > entities,
Beware the anemic domain model. http://martinfowler.com/bliki/AnemicDomainModel.html On Sep 9, 3:36 pm, e36M3 <[email protected]> wrote: > Hello boys and girls, I've been toying around with NH for a while and > now I am trying to figure out how to piece together a n-tier > application with it. Here is my desired architecture: >From what problem does this desire stem? What design issue are you trying to solve by going this route? I am not trying to invalidate your design, just questioning. There may be easier/better ways to build your application without the overhead of an overly complex architecture. > ASP.NET Webforms - The front end will utilize DTOs to communicate with > the Service Layer. I hope there's a good reason for that, otherwise you're going to perform a lot of back and forth mapping for little gain. NHibernate is already mapping to your domain objects. Now you're going to do two mappings. NHibernate -> domain object -> DTO & back. There's times to use this, certainly. Just make sure. > 1) Map the DTOs back to entities, Yes, you have to map back to a domain entity so you can persist it/ update it. > but as the result these are not real > NH entities, They're your entities. Nothing makes it an "Nhibernate entity" This isn't LLBLGenPro :-) > because none of the proxies would be populated since the > objects weren't generated by the ISession to begin with? It's still your object. The trick is getting NHibernate to persist it, not own it. > 2) Lets say I have now a Row entity. Calling ISession.Update(row) > doesn't work because the ISession is not aware of the row. I believe ISession.SaveOrUpdate will persist a transient object. Look up transient objects in the docs, but I'm pretty sure that's the way. > Now I know > you can merge in (Lock?) objects that were generated from other > ISessions (detached), however in my case the objects weren't generated > by the ISession to begin with, they came from DTOs. How do I overcome > this? It's just a simple detached object. Forget the DTO aspect of your design for a second. Imagine you load an object from the ISession and then you serialize it and send it over the wire to an application. At that point - as soon as it is serialized - it's detached. So when it gets back to the app server NHibernate acts like it's never seen the thing before, and you have to get NHibernate to re-associate it with the ISession. And as far as I know, that's what SaveOrUpdate() is for. (NHibernate gurus will correct me I'm sure). > The obvious answer is I have to query the session to first > isolate the row I want to update, then update it. Isn't this bad > practice though since I am making 2 database calls? You could do that, or you could let NHibernate do it, since it's got the two levels of caching to utilize. But let's say you wanted to do it manually yourself: If the object was queried by the same ISession then querying the ISession is going to hit the cache, not the database. At that time you're going to get the instance that NHibernate cached. Then you could copy values from the DTO to the cached object and ask NHibernate to persist the changes. But the caveat there is that your ISession is going to have to hang around long enough for that to happen. Maybe that's not an issue, depending on how you design and consume your services. > > Please help me wrap my mind around this, thank you! I'm just hoping I didn't confuse you further :-) -Chris --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
