Our application provides an user interface to another system with a data schema that is not within our control. Our application uses CSLA to create business objects to allow editing of the data in the third party system. However, as the third party data schema evolves we have to evolve with it. However, at any given time our customers can have any version of the third party system with a different data schema. Therefore, our application needs to be able to adjust to whatever supported version of the schema that the customer happens to have.
We have looked at possibly using the Strategy Pattern to solve this. Essentially having a base class that supports the lowest version of the data schema and then having derived classes to support each subsequent version. In turn, we would have a factory that returned the class that corresponded to the current version of the data schema. However, we are concerned with the possibility of a long and confusing inheritance chain this may cause. Is there a better way to solve this problem? Possibly with composition instead of inheritance?
I don't know how crazy the differences in your data schema could be. One of the common things is the notion of client defined custom fields.
We leverage a businesslistbase on the various entities that have custom properties. For example, an organization might have one of these businesslistbases, a contact might have one of these businesslistbases, etc.
So we might have a CustomPropertyList fo CustomProperty BOs. You could go so far as to have an ICustomProperty interface and have different types of properties within the CustomPropertyList. Each CustomProperty has a "Value", a "Name", perhaps a "Type", perhaps IsRequired which can be enforced through a business rule on the Value property of the CustomProperty, perhaps the type dictates what a valid value is and a business rule is applied there. (If you don't use ICustomProperty / polymorphic custom property type classes, you really have to leave value as an object or string and do validation upon it).
It's a little different than a traditional businesslistbase in that we don't allow a user to remove or add custom properties in the businesslistbase, they can just modify what is there. Also, data access isn't about inserting or updating individual rows in our case; largely, the parent that contains the businesslistbase of custom properties handles the data access for it.
Within Create and Fetch, the CustomPropertyList is established with all the custom properties for the client in question. So, in a multi-tenant environment we can support different customizers with different custom fields.
My answer may not congeal with what you're asking, but just wanted to throw it out there.
That you for the response! We actually have the same requirement of supporting client defined custom fields. However, we solved it a little differently by using the static RegisterProperty method on the base business object to define the custom properties and then using a Custom Property Descriptor to show those custom properties as regular properties at run time. We are able to assign business rules to those customer defined properties as well. I suppose I was resisting using the custom property functionality to support concrete version changes of the third party schema. However, after your response, I am not sure why I am resisting that. It could actually work quite well. I will see if I can get this working.
Thanks again!
Just curious, but how do you support more than one client at the same time when registering properties normally via RegisterProperty? The known properties and rules for a class are established upon first instance, no?
Or do you not have to worry about multi-tenancy?
In our application the business objects are created just on the client that is using the app that moment. This isn't a web app and we are also not passing the business objects back and forth with the server. We simply use csla to give us the business object framework on the client but we rely on the the third-party system that we are integrating to for the remote api. In that sense, multi-tenancy is provided by the third party api.
Copyright (c) Marimer LLC