Cairngorm Enterprise... > ...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.
All the business rules... wow. OK, please give me a hint... what kind of rules are we talking about here... ? On 12/11/06, Lachlan Cotter <[EMAIL PROTECTED]> wrote: > > > > > > > > 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? > > > -- ::::: Aldo Bucchi ::::: mobile (56) 8 429 8300
