I have multiple objects that contain a field Statu. Status can be one of 3 values Active, Inactive, Discontinued. I need to default it to Active.
I have a my own businessbase class that overrides MarkNew. I did this to reset the isdirty flag when adding new items.
I'm thinking of adding an overrideable sub named SetDefaults to my base class that will be called by my MarkNew. This way my objects can just override setdefaults to populate default values, without setting the dirty flag.
Does this make sense?
Thanks
Mike
Rocky,
Setting the values through the Properties can sometimes land you into trouble because setting a property triggers a Rule evaluation which results in calls to IsValid, IsDirty etc and since the object is still being created and therefore some other parts of the object, by definition, would still be Null, you can easily get Object is Null errors. And these tend to be real head scratchers.
Jav
Rocky,
Thanks for the help.
I went down this road because, I'm using the CSLA templates to generate splitbase. The template puts DataPortal_Create() in the base. I didn't want to readd the defaults after regenerating base and came up with this workaround.
Should the templates change so DataPortal_Create() is in the user generated unit?
On a side not I need to override marknew so I only prompt for save if new records are modifed by the user.
Thanks
Mike
I realized I can handle the defaults by overriding DataPortal_Create() in the user generated unit.
Thanks
Mike
I use split classes too.
I decided that DataPortal_Create should call an Overridable Sub SetDefaults.
Some reasons for this:
1. It occurs *after* ActivatorCreateInstance which means all of the Constructors have already run. This is important because if you call an Overridabble method from a Constructor you are not guaranteed that all of the fields have been initialized yet. So there is an FxCop rule against that practice. I had run into some subtle bugs using that style of coding. By using DP_Create to call the Sub you know that all fields have been intialized.
2. This is in line with using the factory pattern to always use DP_Create to create your BOs. Keeps things consistent.
3. I use <RunLocal> in the Gen level class. If I need to hit the database then in the next level I can Override DP_Create and change the entire behavior.
4. By having DP_Create call an Overridable Sub I can code gen as much as I need to and instead of having to override the entire DP_Create method I only have to override this one piece.
5. If I want to keep the Base behaivor then I us MyBase.SetDefaults first and then set any others that are needed for this class. If not, I can skip that and just set what I want.
Joe
PS - Jav - Rocky is recommending setting the field - NOT the Property - from DP_Create. I think you mis-read his comments.
Copyright (c) Marimer LLC