On 11/30/10 11:49 AM, David M. Lloyd wrote:
On 11/30/2010 11:24 AM, Brian Stansberry wrote:
> Ok, concerns duly noted, now I'll think harder about what you are
> saying. :-)
>
> What would this single class do (in the case of writes)? It gets some
> detyped representation of the write, which would include:
>
> 1) the address being updated
> 2) some identifier of the operation being performed
> 3) detyped representation of the parameters
>
> So the model class finds the registered handler for the
> address+operation and passes it the affected DetypedModelElement and the
> parameters?
Again I don't think writes as a generic thing are something we should
deal with. I'll revisit this point on the other subthread though, with
new and exciting insights and arguments.
Ok, I'll wait for that. Will you sell tickets? ;) The main thing I was
getting at above is any core domain model class is going to be clueless
about what to do with updates to a subsystem. It's going to need to
delegate those in some fashion.
The class itself wouldn't be too much of a monster. To be more
specific
about what its responsibilities are:
1) Marshalling to XML - the whole model though, not just piecemeal
2) Providing access to the raw model for the core domain update handlers
(this is functionally equivalent to the level of encapsulation we do today)
Agreed.
3) Providing access to *copies* of the model or a submodel (this can
be
on a base class - AbstractModel perhaps - the basic query API in essence)
If we did provide a generic update mechanism then it would live here as
well, but it's not clear to me how we could make that generic without
adding a lot of complexity.
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat