There are several posts about setting initial values for new entities but none seem to give a definitive answer. I wonder, Frans, if you'd mind giving us your "recommendation" or maybe just your 2c worth on the subject of how and where you think these are best set. I'm talking about a per-field default value (e.g. every project I add I want to have status of "open") not the TypeDefaultValues. Additionally it would be nice if the user saw these values immediately after adding, i.e. it would be better if these defaults were not implemented in the validator.

Best area to add these is in the InitClass* methods, like the InitClassEmpty method and then do that via an include template, bound to Custom_EntityInitializationTemplate. See 'Using the generated code -> Adding your own code to the generated classes'.

Code in a template bound to Custom_EntityInitializationTemplate, will end up right below the code in InitClassEmpty (adapter).

You have to take some measurements to be sure you set the values only when the entity is new. Please see this thread for ideas: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=3194

As mentioned in that thread, some rescheduling in the runtime lib has been done at may 20th, so the init code indeed can figure out if it's handling an empty fields object or a filled one.

Be aware that setting fields makes them 'dirty' and if the entity is added to a graph, will make the end up in the database when the graph is recursively saved.

Here is my 2c worth. In working with JCL framework, we learned (the hard way... believe me) that you can't afford to have expensive initialization code called from any of your BL object's constructor. By expensive I meen initialization code that checks the database or does heavy processing or checks expensive business rules. For that issue we actually had two initialization routines. One initialization routine gets called from the constructors (used from cheep initializations) and another explicit routine (SetDefaults) not called from the constructors. This routine is there for the BL consumer (be it the UI or other BL code) to choose to call this routine knowing that this routine will initialize their BL object with all business logic related data. Of-course, I don't trust the consumer on calling this routine because BEFORE saving the object to the DB, I make sure I do check all relevant business rules irrespective of SetDefaults was called or not. Mainly, SetDefaults() gets called by the UI to initialize the object's fields when creating a new record from the object's BL class.

The final result was that our objects stayed agile and light to be used by entity-collections or VS.NET in design time binding. This is even more critical with VS.NET2005 because for the new Object DataSource feature to work, your class's must have a public constructor; so you could imagine what will happen if you have heavy logic in your object's constructor and VS.NET 2005 initializes your object for design time data binding.

Sorry for the long post, but I wanted to share my personal experience in this subject since it caused us alot of grief and headaches!!