I thought at this point it is worth jumping in to talk a bit about Cairngorm Enterprise, which we are currently working on.
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. Next, we see the application model being responsible for communication with the server-side i.e. it will call remote services, consume messages, produce messages and contain managed data collections. It knows when it needs to retrieve data from the server, it knows when it needs to update server and it knows what to do when data is pushed from the server. 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 is not saying what we do today is wrong, but recognizing different applications have different needs. A simple application certainly doesn't need this level of complexity - Cairngorm today is just fine. >From our observations as the complexity of an application increases we see people treating the ModelLocator as a session for storing data that comes back from the server. There is no application model that shows the entities and their relationships, this is often left to the view to piece together. To help with this we have introduced the concept of an operation, which is effectively your IResponder. When an operation is executed on the delegate it creates an operation, which is responsible for updating the application model. The idea then is that an operation can perform any post-processing, which is required on the data. This allows the application model to be update correctly - quite often when a legacy application is involved the data that comes back from server isn't in a form that reflects how it is going to be viewed. We would deal with that in the operation. 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. We hope by encouraging an application model it will stop people having to code allot of the logic in to the views and also make unit testing easier. If we had a well encapsulated model it would be easier to unit test than a bunch of views. In saying this we can't force people to create an application model nor are you prevented from doing so today. If you want to build an application model in Cairngorm today you can and I know people do. Our goal here is to encourage this in your design and to promote this approach within Cairngorm Enterprise. In addition we want to emphasize security and make it inherent within Cairngorm Enterprise by adopting the "safe-by-default" mantra. We have already done allot of work on Cairngorm Enterprise and there is more to do - so now commitment just now as to when we will release it. Certainly I would like to solicit your feedback on the above and hear your ideas. ________________________________ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Lachlan Cotter Sent: 05 December 2006 11:30 To: [email protected] Subject: Re: [flexcoders] Re: Cairngorm's Anaemic Domain Model My question isn't about the model locator. It's about logic, or lack thereof encapsulated within the domain objects. On 05/12/2006, at 9:59 PM, Tim Hoff wrote: It doesn't matter if it's a "collection of dumb value objects", a component, a state variable, or just a common effect. If an object is used more than a couple of times in the app, put it in the ModelLocator. Remember, everything is an object; instantiated and destroyed like the rest of them (GC?:)). The key is; does the object need to be reusable? If so, make it central. -TH p.s. right on Tom.
