Hey guys. Below are a few changes that have been made to Csla to accomodate things we need to do. I'm looking for advice on maybe better ways to do this as well as insight on whether any of these changes might because unexpected side-effects.
1) Added FetchFailedException : Exception to the Csla library. We throw this whenever we try to get an object that doesn't exist. For our team this was the chosen method as opposed to returning a new object.
2) Added ICslaParent which exposes a single ParentId read only property. All parent objects implement this interface. This aids us in code generation because it's then very easy to get the proper ID column for the parent object during inserts and fetches.
3) Allowing nullable types. As far as Csla is concerned we've only added a set of validation rules we call NullableValidationRules and we've implemented them (for int and decimal) this way:
public static bool NullableIntMaxValue<T>(object target, RuleArgs e) where T : struct
{
e.Severity = RuleSeverity.Error;
int max = ((CommonRules.MaxValueRuleArgs<int>)e).MaxValue;
T? value = (T?)Utilities.CallByName(target, e.PropertyName, CallType.Get);
if (value.HasValue && Convert.ToDecimal(value.Value) > max)
{
e.Description = String.Format("{0} must be less than or equal to {1}",
RuleArgs.GetPropertyName(e), max.ToString());
return false;
}
return true;
}
So, do you guys see any "gotchas" with doing this. And if not, is this something we could get included in Csla? It's becoming a bit of a mess for us to manage the various versions of Csla we are using. We are using 3.6.1 I think in our production environment but are moving to the latest and starting with CslaLight for a Silverlight application.
Also, we have to investigate any breaking changes between 3.6.1 and the latest. The way our servers are managed we're only allowed to have one version of Csla in production (which drives me a bit bonkers at times).
Thanks,
Will
Why change CSLA? Create a base library which can be shared in all projects. In there add the FetchFailedException class (1) and nullable rules (3) and also create base classes that inherit from BusinessBase<T> etc (as discussed multiple times in other threads).
Well, the support for the nullable type validation rules seemed to fall inline with other validation rules. Use them if you want to. So I thought including them directly to csla might be an option.
For the other two topics I guess you're right.
Thanks,
Will
I'm sure CommonRules could be expanded to have many rules, but I don't have time to do that or to maintain a big rule library.
I had hopes that the CSLAcontrib project would end up containing a library of rule methods to share, but that's never really materialized.
So I see three options for you
Copyright (c) Marimer LLC