I think there are some fundamental concepts that are missing about ORM and UOW (unit of work). 1. you shouldn't be too concerned with Ids (PKs) assigning them becomes a responsibility of the ORM. The only time you really need them is when you need to reference the entity outside of the UOW. like passing data across the wire or displaying information to the user. 2. you are working with objects, not records. let the database manage how the objects are related to one another. your quest just needs to know it has a collection of notes. Notes may need to know which request they are associated with, but that's not required. 3. understanding what a UOW (unit of work) is and how it should operate. with NH the session is the unit of work. from the time it opens to the time it's disposed. when you calls (save, delete, or any of the related commands) you are adding an action to a queue. but this queue doesn't execute until the session is flushed*. at this point either all the actions in the queue are successful or all the actions fail**.
*by default a session is flushed when a transaction is committed or session.Flush is called. If you're calling session.Flush there is a problem with your design. **MS SQL identity, or any database generated PK/ID value, breaks the concept of UOW. That is why guid.comb and hilo are the preferred PK strategies for NH. there are also advanced features which can only be used with these UOW compliant strategies as well. I say all of this because it seems like there is a disconnect between how you think this should work, and how NH will work. I'll close with this. the point of an ORM is too reduce the amount of time the developer spends messing around with relational data. This allows the developer to focus on how objects behave with one another and less about the sql required to retrieve and modify the records. That's not to say you shouldn't understand what's happening, but that NH will handle it for you. If you prefer to manage this type of interaction yourself, then an ORM isn't the best choice. instead a framework like Dapper.Net, Massive or Simple.Data may be a better choice. -- You received this message because you are subscribed to the Google Groups "nhusers" group. To view this discussion on the web visit https://groups.google.com/d/msg/nhusers/-/3ng8K4XnbYAJ. 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.
