This isn't bad, but will eventually evolve/devolve into a SDO like pattern http://en.wikipedia.org/wiki/Service_Data_Objects
Essentially, you have ONE DTO type, an object with a Map of properties and their values, a property can be primitive, or another DTO Map, or a collection of either. This approach is relatively trivial to reconstitute on the server via reflection, as you pointed out. On the client tho, you don't have reflection, so it gets stickier. Thinking.... On Jul 6, 9:14 pm, "brett.wooldridge" <[email protected]> wrote: > Ah. So, am I correct that it is the case that you want to pass these > through RPC as MyObject, rather than specific sub-classes? If that is > not case, if specific RPC calls take specific subclasses, you might > try this pattern: > > interface IMyObject { > // getters > // setters > > } > > class MyObject implements IMyObject { > private state > // implemented getters/setters > > } > > class MyObject1 implements IMyObject { > private MyObject delegate; > // implemented getters/setters delegate > > } > > If you're using Eclipse (I don't know about IDEA) generating the > delegate methods is trivial (right-click, Source->Generate delegate > methods...). However, I assume it is because MyObject is traveling > over the wire that you have this issue. > > So, if your RPC method signatures do take the base MyObject class, > then I would recommend "optimizing for the wire". Its never pretty, > but in the RPC world (going back to Corba or RMI even) sometimes you > have to break your perfect OO abstraction for serialization > considerations. In this case, here is what I would consider: > > Create a single "wire class" to transport the information in these sub- > classes. Something akin to the Java Properties class. Just a bag of > attributes and values, with a class descriminator. > > class MyWireObject { > private String className; > private Properties properties; > > } > > Put an abstract toWireObject() and fromWireObject() in MyObject. In > each sub-class, implement the toWireObject() method and fromWireObject > () method -- each subclass knows it's class name and what properties > it needs to transport. The fromWireObject() method takes a > MyWireObject and sets the state of the instance from it. Replace > MyObject in all the RPC calls with MyWireObject, and on the server use > a touch of reflection to rehydrate the subclass. Pseudo-code: > > Class clazz = Class.forName(wireObject.getClassName()); > Object object = clazz.newInstance(); > Method method = clazz.getMethod("fromWireObject"); > method.invoke(object, wireObject); > > I consider browser CPU time basically free for all intents and > purposes. Unless you're throwing dozens of objects per-second over > the wire, it won't matter. There is a slight server impact due to the > reflection and hand-rolled rehydration, but my guess is it won't show > up high in the context of your larger application. Other than that, I > don't have any suggestions. > > -Brett > > On Jul 6, 10:46 pm, Joshb <[email protected]> wrote: > > > > > Brett, > > > Thanks for your reply. The short answer, is the 'MyObejct' class has > > about 10 properties in it. It is a social networking application, > > with many 'social objects'. Each object inherits properties from the > > main object, so I don't think an interface would do. > > > On Jul 6, 12:20 am, "brett.wooldridge" <[email protected]> > > wrote: > > > > Are these classes truly sub-classes, or are you using MyObject as a > > > generic "Object" (in the Java Object class sense) that is > > > serializable? > > > Meaning, does MyObject have a bunch of state that is also shared by > > > MyObject1..50? Or is MyObject pretty much empty with all of the > > > state in the individual sub-classes? > > > > If that is the case, what is the purpose? So you can pass MyObject1.. > > > MyObject50 type objects through the same RPC method? > > > > I'm asking because it's hard to imagine (in Object Oriented terms) a > > > reasonable scenario in which there is a base class with truly shared > > > state across 50 subclasses. Sure, such cases exist (witness Java > > > Object or a UIObject type class), but they are relatively rare in > > > typical > > > domain modeling. > > > > It seems a mistake to have something like: > > > > class MyObject { > > > protected int id; > > > > } > > > > class MyObject1 extends MyObject { > > > // more state > > > > } > > > > yada yada... > > > > class MyObject50 extends MyObject { > > > // more state > > > > } > > > > If you can provide some context around your modeling domain, > > > it will be easier to answer your question. But on the surface, it > > > sounds like you need to rethink your object model. > > > > If MyObject is empty or fairly empty of state, you might dodge the > > > bullet (without solving the modeling issue) by making it an interface. > > > By doing so you can still have one RPC method that takes the > > > MyObject interface without having truly polymorphic subclasses. > > > > -Brett > > > > On Jul 4, 11:46 am, Joshb <[email protected]> wrote: > > > > > We are currently working on a very complex project that has: > > > > > * A very large set of Data Objects which all extend from a Single > > > > Super Class ( eg. MyObject, MyObject1 extends MyObject, MyObject2 > > > > extends MyObject ... MyObject50 extends MyObject) > > > > * each of these objects have 10-30 properties, often consisting of my > > > > varients of MyObjects > > > > > As a result, when I try and bind a RPC service ( GWT.create > > > > ( MyObjectService.class ); ), it is taking 10+ seconds to bind. > > > > Running in debug hosted mode using -extra indicates that, in fact, the > > > > log output of the RPC binding is over 17,000 LINES!!!! > > > > > I have broken up my application into several separate GWT modules, and > > > > roughly each one has its own RPC service. Each time it is called and > > > > bound using deferred binding, there is this 10+ second delay. This is > > > > obviously slowing down development/testing, and probably doing a lot > > > > of other bad things at the same time. I'm sure there must be a better > > > > way. > > > > > I am very curious (anxious) to know others thoughts on how to avoid > > > > this situation when dealing with large, intertwined models. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
