Thanks for the input.Could you give me some more insight on how you use the command pattern? (how it appears in the front/backend interface/classes, and flow)..
The implementation of the pattern is pretty standard stuff: interfaces Command + Result + Handler. Concrete commands have an annotation pointing to the handler that executes the command. The handler takes the command as input and does all the work.
But what about using the issue mentioned in SO (duplicated serialization code for same class in different method in different Async interfaces)?
All the FieldSerializers are only generated once as they live next to the type they serialize. However each RPC service references a TypeSerializer which references all required FieldSerializers for that RPC service. If you have multiple RPC services and each serializes TypeA then the FieldSerializer for TypeA will be referenced by all TypeSerializers (each map has an entry for TypeA).
Speaking of command pattern: if you have multiple command services and each service has a distinct root command interface (ModACommand, ModBCommand) then the only things that might end up in multiple TypeSerializers are serializable JRE classes and common DTOs used in multiple command services. These might be less than you think. Just take a look at the serialization policy files of your services to see how much types are common.
-- J.
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment