To start off, your last thought process was probably the best. Letting NHibernate generate the ID's for you saves you a lot of the trouble. You can also tell NHibernate that you'll be generating ID's, and in that case, you need to use a Version element to keep track of if your object is brand new or an update. As for a place to get started, you can check out the wiki for Fluent and go through learning some of the ways to use Fluent with NHibernate, but if you're interested in learning about NHibernate in more depth, you might try: http://codebetter.com/blogs/ian_cooper/search.aspx?q=introduction+to+nhibernate
Just follow all of those through, it's a pretty good starter tutorial for using NHibernate in general. :) On Mon, Apr 20, 2009 at 7:10 AM, Bill <[email protected]> wrote: > > Hi, > > Thanks for the great info. This is pretty much what I was thinking as > well. I've also noticed that there have been recommendations on this > topic for not using generated id's or composite keys. When I think > about it, I'm not sure how, with a list of customers that each has a > list of orders each of which has a list of orderItems, this can be > done with a single id? Maybe there is something more general that I am > missing but it would seem that orderItems would require a minimum of a > customer id and a order id to find the orderItem(s) for a customer. Is > there something else that I might read to help me understand this? In > this type of design, is it possible to let NHibernate generate all the > id's and for the application not to have to worry about it? > > Thanks in advance and forgive me for this being such a newbie > question. > Bill > > On Apr 13, 6:30 pm, Hudson Akridge <[email protected]> wrote: > > Yup. NHibernate keeps track of all of that in the session/transaction, > using > > a Unit of Work pattern. How you declare your mappings has a lot to do > with > > whether or not something is saved/deleted/inserted properly. > > If you've set up the cascades (and inverse mappings if you've got a > > bi-directional) correctly, then NHibernate will do this with no problem. > If > > you're working on objects that you've retrieved from a persisted state > using > > NHibernate, then you don't even need to call a > > Session.SaveOrUpdate(CustomerObject) to save the customer and all of it's > > children. > > > > Working with the concept of dirty versus clean objects takes care of this > > all for you. NHibernate will look at the objects you retrieved during > your > > session, and if it notices that any are dirty, it will generate the > > appropriate updates. If that object contains other objects which were > > removed/added/updated, the appropriate SQL will be generated for those as > > well, all the way down the line recursively until everything in the in > > memory object model has been checked. > > > > > > > > On Mon, Apr 13, 2009 at 3:47 PM, Bill <[email protected]> wrote: > > > > > Hi, > > > > > I have a heirarchy of classes where each contains a list of the next > > > and so on. Pretty straightforward. If I have a list of Customers that > > > has a list of Orders that has a list of OrderItems, if I add an Order > > > and delete a OrderItem do we have to keep track of what is an Update > > > verses a Insert verses a Delete or if I Save at the top level > > > (Customer) will NHibernate figure out what SQL to generate? Please > > > forgive me if this is a stupid question. > > > > > thanks! > > > Bill- Hide quoted text - > > > > - Show quoted text - > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Fluent NHibernate" 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/fluent-nhibernate?hl=en -~----------~----~----~----~------~----~------~--~---
