So, one of our developers is binding a criteria object to their silverlight UI. They want to use this criteria as the criteria for a fetch of a read only list. They have a requirement such that when searching, the criteria.begindate must be less the the criteria.enddate.
So... my question is, would it be ok to use a BusinessBase object as the criteria param for the dp fetch? This way we can leverage the CSLA validation subsystem.
I agree 100%. I have been using BB objects to bind to complex criteria screens for a long time now. I even added a GetFilter method to produce the "Where clause" based on the input values. For example the user may have 10 various values to choose from but may only pick 2 of them. So the GetFilter method recognies which ones are not needed and only produces the minimal Where clause. The BO uses the Validation subsystem to ensure that the criteria object is valid prior to using it to fetch something else in the database. My ROC's have methods that accept this BB object and then call get filter to append to the SQL statement. It can get confusing if you call these things Criteria BOs because they are very different from what a normal criteria BO is. But they work great for binding to screens, validating data and producing the filter for the SQL.
CSLA 4 is eliminating the ICriteria interface, which means a BusinessBase object can be a criteria object without even that extra detail. (and between you and me, you can get away with ignoring ICriteria in 3.8 too as long as you only use the generic DataPortal methods)
May I know why the ICriteria interface being eliminated in CSLA 4? Does this mean we have to use the BusinessBase even just for simple criteria?
Thanks in advance.
ICriteria is being removed because the non-generic data portal methods are being removed, so there's no need for you to pass type information through the criteria. The data portal already has the type information.
So it is lifting a restriction. In the current CSLA 4 bits any serializable object can be a criteria object (IMobileObject on SL). I'm hoping that we can remove that restriction as well, so you can use primitive types, but right now the MobileFormatter doesn't know how to handle a standalone primitive value.
What this means is that I'm keeping SingleCriteria<T, V>, but have added SingleCriteria<V> since the "T" in the older one is just wasted bandwidth now. And CriteriaBase<T> is now generic like BusinessBase so it has the same friendly RegisterProperty() overloads.
But basically any type that is Serializable (and implements IMobileObject on SL) can be a criteria in CSLA 4.
Copyright (c) Marimer LLC