Friday, February 02, 2007
serialization and SOAP and...
I am struggling to figure out the best way to procede with regard to the card in hand webapp. My data classes have a custom serialization for the superwaba library that I was using in the first two versions of the application. It all looked okay to simply extend that, and use it for j2me. I made a j2me implementation and it works find for serializing all the data.
But the problem I'm having is that now I want to extend or project these data classes into the rails world - or something like that. At first I thought I needed something of a separation of logic from the data. That is have plain empty bean classes and a parallel class for all logic. I could then use the beans easily within a webapp framework (I'm using xfire at the moment). But then I came accross this wonderful anti-pattern description.
I completely see this anti-pattern being what I was about to do: separate all the logic out of its associated logic. Wrong. However, since I'm resolved to implement a webapp to expose both data and specifically logic to the world I do have to consider how I keep the application layer thin - keep logic out of the webapp layer, when I'm accessing logic only available in my data classes on the Java webapp.
Right right. It doesn't make sense to have useless structural code. We all like the idea of MVC, but it is senseless to brainlessly recreate data only classes and not associate it with the appropriate logic. Not that any non-Java SOAP client would be able to use this logic...
At the moment I'm madly converting all of my data classes into Beans, so that I can send them over the wire. But I'm beginning to doubt that this is the best method to attain my end. Its either that or, recreate a custom parser on each end for my flavor of binary. That doesn't sound fun.
