I wonder why a DTO pattern was introduced. Basically I think this adds an own level of complexity and another abstraction. And the current domain objects are PJO's, so no technical need for DTO's. And basically somehow this may relate to the nebulous "API" which isn't yet decided?
In the most current applications I face it was decided against DTO's, because it safes a lot of effort for a mostly unecessary abstraction...
Or what do you think?
There is several reasons for this:
- the GWT console shouldn't be tight to a particular jbpm version
or bpm runtime in general (at least we try to avoid it)
- GWT only supports a limited set of JDK classes. Pulling in the jbpm model would cause all kind of dependency problems, which most result in GWT compiler errors due to unkown / unsupported classes
- the dto's are fit to support particular console usecases. not less and not more
- last but not least, the jbpm3 model is directly exposed which IMO is wrong from the beginning
i think a BPM generic console is out of scope.
after we make the fork to jbpm 4, we should re-evaluate the need for dto's.
limited support for GWT classes can be a showstopper.
the jbpm 4 API classes should actually be usable for this purpose. at first thought the console would be a good challenge to see if the API classes are ok.
but i'm not against the dto's per se. in the designer we had to introduce them as well. but for jbpm4, i would like to know the reason.