Let me start by describing my use case.
I have a system to allow a user to do a return (say like a tax return). Currently, there is an admin side that allows admins to define support documents for a return. They all display.
The new requirement is to filter the list of supporting documents depending on values from the return. For each document, a list of criteria can be configured by administrators which define if the document should show for each particular return. I have a fixed set of fields that can be used, various operators (equals, contains, greater than, etc) and a user defined value (string for string fields, date for date fields, etc.).
My decision was to add a method to the SupportingDocument RO object that takes an article (done with interfaces to make unit testing easier). In this way the list can be filtered easily.
I'm now implmenting objects which do the comparisons, basically these reperesent each operator. Its their responsibility to do the comparison with the value on the return (they already know the value defined by the admin).
This is where I'd like some feedback. It looks like the Csla.Core.FieldManager.FieldDataManager can read the value. I have no problem doing this, I'll just have to put an interface around it for the unit tests, but I just wanted to be sure there's no better option.
Also, with the design of the objects; they'll have a reference to an object field which is the value defined by the admins, and an IPropertyInfo, which is what I'm planning to use to get the value in an aribtrary way. I realize that PropertyInfo<T> doesn't serialize and is recreated on both ends of the DataPortal. So these operator classes, should I just build them on the client side of the dataportal? That implies that I'd need to have the RO object carry around the data needed to do so. Not a big deal, but I'm wondering how best to handle that as well. Simple DTOs that inherit MobileObject? The value will be a primative type (string, DateTime) and probably just some arbitrary primative type to tell a factory what property info to grab.
Well I went ahead with the above. The only thing that tripped me up a litle was FieldDataManager returns null it seems if the property has never been set. But that's easy enough to handle. So unless someone has a better way, or a reason why this shouldn't be done, I think I'm set.
Copyright (c) Marimer LLC