Hi Peter,
Thanks for this information, it has certainly helped to clarify some
things in my mind.
With Cairngorm Enterprise one of goals is to promote an application
model on the client (RIA) and a domain model on server. We see the
application model being a good OO model that reflects the UI and
tells us about the entities and their relationships that we are
surfacing. It will also encapsulate all the business rules that
apply to the UI. I see this being different to the domain model and
the business rules that reside on the server.
The thing that is most interesting to me here is the talk of
relationships because this is what seems to be lacking somewhat in
the current Cairngorm paradigm. Not to imply that it can't be done,
just that it doesn't seem to be part of the standard practice.
This sort of shifts the concept we have at the moment, whereby you
call a command, which may invoke a service via a delegate. In
essence we are going to move the delegates behind the model and
have the command call an operation on the model.
This sounds promising. Where does this put the service locator?
In essence it would be nice to see VOs / DTOs being used for
transporting data rather than making their way in to the view via
the ModelLocator.
Again, glad to hear this is an issue for others as well. In simple
cases, the VO is adequate because it sufficiently represents both the
domain object and the view you want to take of it. When the
relationships become more complex however, inconsistencies begin to
arise. For example, when you have many-to-many relationships and such
and you want to be able to traverse the object graph in bindings or
whatever, you need to construct a more interconnected object graph
rather than a collection of records as it were. Then you have the
problem of how you get from A to B. Is there a best practice you are
advocating for mapping and building object graphs out of data in
DTOs? or is it left up to the specific requirements of the application?
