Christian,
You are both right and both wrong. In other words it doesn't really matter which way you do it. For convenience and peace of mind you may just want to accept the way the template does it though.
OK - so why doesn't it matter?
When you use New on a BO which has an underlying Identity column in the DB, the value in the BO is completely irrelevant until it is saved. So you can either assign it a "phony" value of 0 through the parameter, or else let the field default to its value of 0 and skip the parameter assignment. Either way mID is going to be 0.
Now if it matters to you, you can always assign a different default when creating the field or when you go through DP_Create.
All of the above is true for root objects since they do not need to be Unique. For child objects which are contained in collections, you should assign a different value when you create each one - this assumes that GetIDValue returns mID. I almost always assign the integer which is the count of the collection at the time the child is created. Thus it starts with 0 and increments by 1 each time a child is added.
When a root or child is saved to the DB (an Insert operation), you also need to retrieve the newly created identity value and update mID with it. That way future edits of the same BO will result in Update operations of the correct row in the DB.
Joe
Joe,
Thank you for taking the time. I agree that there is no harm to have it this way. I use the templates from CodePlex sparingly, but increasingly more as time passes, but this is something I didn't notice in my initial uses and surprised me when I inspected the generated code yesterday. I guess I was wondering if there was some paradigm or design nuance that I was missing since I did not expect to see that parameter on that factory method.
Happy Holidays,
Christian
Copyright (c) Marimer LLC