Den 15. des. 2009 kl. 10.54 skrev Bob Jolliffe:
> The real question is a general one; how do we think the api (and the xml
> formats we want to support) will evolve in the future? I don´t think we can
> avoid the rising cost of changes to the domain model, but we should try to
> make a concious choice on where we think we are going, before I create a new
> mapping solution. Some possiblities:
>
> 1) Proposed jaxb mapping, generally not supporting multiple xml versions -
> visible, easy, but no support for old formats
>
> I have for some time been proposing to Lars that the marshalling and
> unmarshalling of domain objects should be part of the API. There are lots of
> advantages but I have come around to his thinking that decoupling these is in
> fact important. Primarily because I think there will be ongoing tweaks to
> the domain model. Particularly I expect we will do at least one more
> refactor of mcdonalds (categories, combo's etc).
>
> 2) Something like the existing "mapping layer" - low visibility, easier to
> support multiple separate xml versions (but rising uncertainty of entity
> changes for every version)
> 3) jaxb and "versioned" domain models - visible, reflecting the (real)
> complexity of different api versions in the domain model
>
> I don´t think we are at a point yet where we are sold on the approach we
> choose now, but obviously I would prefer not have to rewrite the mapping
> approach in the near future. I haven´t really looked at the feasibility of
> trying to do something like 3, but I think it should be to introduce such a
> model on parts of the domain model when needed, starting from 1.
>
> Personally I prefer to try 1, what do you think?
>
> My thinking was some combination of 2 and 3. A jaxb set of
> marshalling/unmarshalling classes which are bound to a namespaced version.
> And then mapping these to the domain model. Not as neat as a direct jaxb
> mapping but more flexible.
I´m not entirely convinced that it will be that much more flexible. I mean, it
really depends on how important backwards compability will be, and currently
the domain model is a bit too changing to warrant it. So, at the moment I tend
to think that planned breaking changes to a single export format would be
preferable. The added complexity and extra resources needed to maintain a
separate mapping layer and multiple versions just seem to outweigh the
benefits. If we don´t have that many concrete use cases in the short term, the
cost of upgrading them seems preferable?
On another note, I don´t think jaxb makes a lot of sense if we go for a
separate layer. I would tend to favour a solution more like the current
framework, simpler and with less boilerplate overhead.
Jo
_______________________________________________
Mailing list: https://launchpad.net/~dhis2-devs
Post to : [email protected]
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp