I'm with you Alex. The gripe seems to be duplication and object graphing. With client/server architecture, this is common place and often unavoidable. Usually though, this has to do with mapping data classes, but business logic always seems to fall into this category as well. My take is that it's all about organization. Cairngorm is not a savior, but rather a sheperd.
-TH --- In [email protected], "Alex Uhlmann" <[EMAIL PROTECTED]> wrote: > > Hi Lach, > > there many ways to use Cairngorm. I agree with you completly, it's of > vital importance to refactor the right functionality from both, views > and commands into model objects that mean something to your use case. > Then, this functionality can also be easier unit tested. Just lets keep > in mind that there's also view functionality like effects code etc, > which wouldn't make too much sense in a model, instead they can often be > refactored into utility classes ( which you might want to call view > helpers ;) ) > > However how your model is going to look like depends on your specific > needs. Cairngorm doesn't tell you how to design your custom model or > your custom view. It's the infractucture around that. > > My blog entries around that, which Douglas pointed out, have the indent > to show one possible route to go towards this direction. Nevertheless, > it's difficult to show that in examples, since there's a tradeoff in > completeness and complexity vs. easy to understand examples ....and most > importantly...time. ;) > > Best, > Alex > > > Alex Uhlmann > Consultant (Rich Internet Applications) > Adobe Consulting > Westpoint, 4 Redheughs Rigg, > South Gyle, Edinburgh, EH12 9DQ, UK > p: +44 (0) 131 338 6969 > m: +44 (0) 7917 428 951 > [EMAIL PROTECTED] > http://weblogs.macromedia.com/auhlmann > > > > ________________________________ > > 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. >
