One thing I’ve noticed with the CSLA was the “necessity” of creating a special “Criteria” class for each portal request. With the advent of CSLA 3.5, this has been mitigated somewhat by the introduction of a SingleCritiera<T, V> class.
One thing I did noticed that sparked my interest was the method signature of the DataPortal.FetchChild/CreateChild, etc. methods and the corresponding resolution to the appropriate Child_XYZ method.
The DataPortal.*Child methods have a “params object[] parameters” signature. Is there any possible to retrofit the DataPortal.Fetch/Create methods to have a similar signature?
In this manner, we could easily do the following:
DataPortal.Fetch(myInteger, myMinDate, myMaxDate);
And see the call resolve to the following method:
DataPortal_Fetch(int value, DateTime minDate, DateTime maxDate) {}
All of this would occur without a special class. Obviously, this would only function if the “objectType” parameter was supplied via a generic call: DataPortal.Fetch<MyClass>(…).
Another thing I noticed was that when using a single parameter, it wasn’t truly necessary to create custom “Criteria” object, except in the case of integer – mostly because of the way the “EmptyCriteria” value is supplied and checked inside the DataPortal method resolution. If the params object[] parameters solution is too complicated, wouldn’t it be “nicer” to have the EmptyCriteria be some funky type, like an unsigned byte or something, and then the portal method could check for that type instead of the extremely common integer?
Copyright (c) Marimer LLC