At my place of employment, we are having a religious battle over developing a framework to connect to backend systems. We have decided to either go with a generic framework interface where all business objects send data the same way to and from the framework. The data that would ben sent though would have to be a little kludgey to make the framework generic enough for all business objects. And the data that came back would need to be massaged by the framework into a generic course grained object. This framework would be VERY black box and be very smart on data parsing, etc.
The other approach is using java objects. Instead of sending kludgey parameters such as hashmaps within hashmaps, we can just instantiate the appropriate object and use setter methods, which is very clean. We can then use Castor to convert the object to XML and use XSLT to format the data to the back end. The return data would then be encapsulated in this object and easily accessed by getter methods. However, as opposed to developing data parsing, etc. functionality once, we would have to do some cutting and pasting.
The future is that once the framework is done, there will be very minimal (if any) modifications for about 2 years.
Have any of you had a similar dilemna? Do you feel it's nicer for business objects to use custom objects for their dirty work, or one generic framework/ interface? Why?
Thanks a million for any input,
"The future is that once the framework is done, there will be very minimal (if any) modifications for about 2 years. "
Ouch. Assumption is the mother of all fuckups.
Sorry to be brutal but the old saying is true. Assume you will have to change it next week and design accordingly.
What you really need is Mirror, a library Im writing for open source, which dynamically looks at your data and knows how to handle it. However, unfortunately, it is not completed even my rough draft yet.
I have had the same problems in many companies and that is why I developed the concepts that Mirror is based off of. I am busily extracting them into a general purpose library.
As to your question, I couldnt really answer it without more knowledge of your system. However Id plan for the unplanned for if i were you. If that leady you to Java objects, then that is the way to go.
I may be completely off target here, without knowing more about your project...
Is the generic framework going to be so unwieldy to use that application developers will end up writing their own object layer on top of it? Then maybe the framework should go in that direction itself.
And will that not also address the cut-and-paste issue? You develop a powerful and generic (if difficult to code) set of classes to do the data conversion and transfer, and on top of that, also develop the tools to create programmer-friendly wrappers around it.