Re: [flexcoders] Re: Cairngorm's Anaemic Domain Model

[Aldo Bucchi]

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

Re: [flexcoders] Re: Cairngorm's Anaemic Domain Model

[Lachlan Cotter]

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?

RE: [flexcoders] Re: Cairngorm's Anaemic Domain Model

[Peter Martin]

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: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Lachlan Cotter
Sent: 05 December 2006 11:30
To: flexcoders@yahoogroups.com
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.

 

 

Re: [flexcoders] Re: Cairngorm's Anaemic Domain Model

[Daniel Wabyick]

You may also want to read up on the executeBindings() and 
executeChildBindings() functions ... You may be able to call that on 
initialization and get your binding to fire.

Lachlan Cotter wrote:
>
> The valueCommit event fires when the control is changed 
> programmatically. Docs sa also on user interaction, but I'd verify 
> this first.
>
> Tracy
>
> 
>
> *From:* flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] 
> *On Behalf Of *Dmitry Kochetov
> *Sent:* Wednesday, December 06, 2006 6:24 AM
> *To:* flexcoders@yahoogroups.com
> *Subject:* Re: [flexcoders] Combo box selectedlabel problem.
>
>
> Hello,
>
> Try to dispatch event from your combo manually, like
> myCombo.dispatchEvent( new Event( Event.CHANGE ) );
>
> haravallabhan wrote:
> >
> > Hi all
> > I want to set the initial value of a combo box to the first item when
> > the application loads and load another component according to the item
> > selected. The functionality works when I use a change action in the
> > combo box.That is it works when I manually change the item of the
> > combobox. But it is not working when the application is loading. That
> > is the event is not listening when the application loads.
> >
> > Examples I have say 5 items select Code,1,2,3,4. So the default vaue
> > will be select code.A alue for 1 will show an apple image in another a
> > componentand so on. When I manually change to the value 2 the image
> > changes and when I change to 1 the image is changed to apple.
> >
> > I want the application to start with the initial value of the combo box
> > set to 1. So that the initial image will be apple.Though the combo box
> > is set to 1 there is no image shown. Only when I do it manually it
> > shows up. Can any one help on this regard.
> >
> > Thanks in Advance
> > Hara
> >
>
> -- 
> Feсi quod potui, faciant meliora potentes
>
>  



--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/flexcoders/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/flexcoders/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:[EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED]

<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
 

Re: [flexcoders] Re: Cairngorm's Anaemic Domain Model

[Douglas McCarroll]

What's "OP"?

 > Cairngorm doesn't allow the model to talk to the backend.

Huh?

But yes, the hibernate adapter model also looks very attractive to me. 
There are some questions about how to implement Flex Data Management 
Services in Cairngorm - IResponder doesn't include a conflict() method. 
I know that Adobe consulting has implemented FDMS - search Flexcoders 
for "cairngorm" + "fdms" - if I recall they hadn't finalized how they 
deal with this a few months ago...

ServiceLocator includes DataServices in Cairngorm 2.1, but it still 
isn't clear (at least to me) whether there's a standard way to pass in a 
conflict() method.

Have you found your way to clarity on this, Adobe?  :-)

Douglas


-

Douglas McCarroll

CairngormDocs.org Webmaster
http://www.CairngormDocs.org

Flex Developer
http://www.brightworks.com
617.459.3840

-



Ralf Bokelberg wrote:
>
> Yes Bjorn
>
> As i understand the OP, the problem is, that in a normal Cairngorm 
> application the rich model sits on the server. What we see on the 
> client is only the part of the model, which is needed to drive the ui. 
> Now if you want to move the rich server model to the client, you have 
> to manage the fine grained interface between the model and your 
> persistence layer on the backend. This can't be handled by Cairngorm, 
> because Cairngorm doesn't allow the model to talk to the backend.
>
> So yes, using the FDS Hibernate adapter for example probably makes up 
> a good prototype of OPs problem: A client, which talks to backend via 
> the hibernate adapter. This means, we have all the business logic on 
> the client and the backend is just persistance.
>
> Cheers,
> Ralf.
>
> On 12/6/06, *Bjorn Schultheiss* <[EMAIL PROTECTED] 
> > wrote:
>
> Hey Ralf,
>
>
> For the rich-model implementation would this benefit from FDS, or
> some other data-sync framework?
>
> Regards,
> Bjorn
>
> On 06/12/2006, at 10:31 AM, Ralf Bokelberg wrote:
>
>> Though Cairngorm doesn't prevent you from creating rich models, i
>> think it fits better for this kind of crud application with a
>> rather flat model. In fact the model is  little more than a cache
>> of serverside objects. User gesture, update cached objects,
>> update view.
>> If i was to implement a rich model, i would let the model handle
>> the backend directly and make the controller a real
>> frontcontroller, which maps usergestures to model method calls.
>> You could still use cairngorm framework, it's just a slight shift
>> of responsibilities.
>> Cheers,
>> Ralf.
>>
>> On 12/5/06, *Lachlan Cotter* < [EMAIL PROTECTED]
>>  > wrote:
>>
>>
>> Thanks Alex,
>>
>> One thing I'm looking for is validation that there is a need
>> in some applications to construct an object graph of sorts to
>> describe the model beyond an array of records to be CRUDed. 
>> Surely I'm not alone here?
>>
>> If that's the case, is there a best practice for going from
>> value objects delivered from a service, to first class,
>> intelligent model citizens in the domain? One thing I've
>> found confusing about the Cairngorm approach is that models
>> and value objects seem to be synonymous.
>>
>> You thoughts?
>>
>> Cheers,
>> Lach
>>
>>
>> On 05/12/2006, at 11:13 PM, Alex Uhlmann wrote:
>>
>>> 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. …
>>
>>> 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.  ;)
>>
>>
>>
>>
>>
>> -- 
>> Ralf Bokelberg < [EMAIL PROTECTED]
>>  >
>> Flex & Flash Consultant based in Cologne/Germany
>>
>
>
>
>
> -- 
> Ralf Bokelberg <[EMAIL PROTECTED] 
> >
> Flex & Flash Consultant based in Cologne/Germany
>  



--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoog

Re: [flexcoders] Re: Cairngorm's Anaemic Domain Model

[Ralf Bokelberg]

Yes Bjorn

As i understand the OP, the problem is, that in a normal Cairngorm
application the rich model sits on the server. What we see on the client is
only the part of the model, which is needed to drive the ui. Now if you want
to move the rich server model to the client, you have to manage the fine
grained interface between the model and your persistence layer on the
backend. This can't be handled by Cairngorm, because Cairngorm doesn't allow
the model to talk to the backend.

So yes, using the FDS Hibernate adapter for example probably makes up a good
prototype of OPs problem: A client, which talks to backend via the hibernate
adapter. This means, we have all the business logic on the client and the
backend is just persistance.

Cheers,
Ralf.

On 12/6/06, Bjorn Schultheiss <[EMAIL PROTECTED]> wrote:


  Hey Ralf,

For the rich-model implementation would this benefit from FDS, or some
other data-sync framework?

Regards,
Bjorn

On 06/12/2006, at 10:31 AM, Ralf Bokelberg wrote:

Though Cairngorm doesn't prevent you from creating rich models, i think it
fits better for this kind of crud application with a rather flat model. In
fact the model is  little more than a cache of serverside objects. User
gesture, update cached objects, update view.
If i was to implement a rich model, i would let the model handle the
backend directly and make the controller a real frontcontroller, which maps
usergestures to model method calls. You could still use cairngorm framework,
it's just a slight shift of responsibilities.
Cheers,
Ralf.

On 12/5/06, Lachlan Cotter <[EMAIL PROTECTED]> wrote:
>
>
> Thanks Alex,
>
> One thing I'm looking for is validation that there is a need in some
> applications to construct an object graph of sorts to describe the model
> beyond an array of records to be CRUDed.  Surely I'm not alone here?
>
> If that's the case, is there a best practice for going from value
> objects delivered from a service, to first class, intelligent model citizens
> in the domain? One thing I've found confusing about the Cairngorm approach
> is that models and value objects seem to be synonymous.
>
> You thoughts?
>
> Cheers,
> Lach
>
>
> On 05/12/2006, at 11:13 PM, Alex Uhlmann wrote:
>
> 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. …
>
>
> 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.
> ;)
>
>
>
>


--
Ralf Bokelberg <[EMAIL PROTECTED]>
Flex & Flash Consultant based in Cologne/Germany


 





--
Ralf Bokelberg <[EMAIL PROTECTED]>
Flex & Flash Consultant based in Cologne/Germany

Re: [flexcoders] Re: Cairngorm's Anaemic Domain Model

[Bjorn Schultheiss]

Hey Ralf,

For the rich-model implementation would this benefit from FDS, or  
some other data-sync framework?


Regards,
Bjorn

On 06/12/2006, at 10:31 AM, Ralf Bokelberg wrote:

Though Cairngorm doesn't prevent you from creating rich models, i  
think it fits better for this kind of crud application with a  
rather flat model. In fact the model is  little more than a cache  
of serverside objects. User gesture, update cached objects, update  
view.
If i was to implement a rich model, i would let the model handle  
the backend directly and make the controller a real  
frontcontroller, which maps usergestures to model method calls. You  
could still use cairngorm framework, it's just a slight shift of  
responsibilities.

Cheers,
Ralf.


On 12/5/06, Lachlan Cotter <[EMAIL PROTECTED]> wrote:

Thanks Alex,

One thing I'm looking for is validation that there is a need in  
some applications to construct an object graph of sorts to describe  
the model beyond an array of records to be CRUDed.  Surely I'm not  
alone here?


If that's the case, is there a best practice for going from value  
objects delivered from a service, to first class, intelligent model  
citizens in the domain? One thing I've found confusing about the  
Cairngorm approach is that models and value objects seem to be  
synonymous.


You thoughts?

Cheers,
Lach


On 05/12/2006, at 11:13 PM, Alex Uhlmann wrote:

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. …


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.  ;)






--
Ralf Bokelberg <[EMAIL PROTECTED]>
Flex & Flash Consultant based in Cologne/Germany

Re: [flexcoders] Re: Cairngorm's Anaemic Domain Model

[Ralf Bokelberg]

Though Cairngorm doesn't prevent you from creating rich models, i think it
fits better for this kind of crud application with a rather flat model. In
fact the model is  little more than a cache of serverside objects. User
gesture, update cached objects, update view.
If i was to implement a rich model, i would let the model handle the backend
directly and make the controller a real frontcontroller, which maps
usergestures to model method calls. You could still use cairngorm framework,
it's just a slight shift of responsibilities.
Cheers,
Ralf.

On 12/5/06, Lachlan Cotter <[EMAIL PROTECTED]> wrote:


  Thanks Alex,

One thing I'm looking for is validation that there is a need in some
applications to construct an object graph of sorts to describe the model
beyond an array of records to be CRUDed.  Surely I'm not alone here?

If that's the case, is there a best practice for going from value objects
delivered from a service, to first class, intelligent model citizens in the
domain? One thing I've found confusing about the Cairngorm approach is that
models and value objects seem to be synonymous.

You thoughts?

Cheers,
Lach


On 05/12/2006, at 11:13 PM, Alex Uhlmann wrote:

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. …


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.
;)


 





--
Ralf Bokelberg <[EMAIL PROTECTED]>
Flex & Flash Consultant based in Cologne/Germany

Re: [flexcoders] Re: Cairngorm's Anaemic Domain Model

[Lachlan Cotter]

Thanks Alex,

One thing I'm looking for is validation that there is a need in some  
applications to construct an object graph of sorts to describe the  
model beyond an array of records to be CRUDed.  Surely I'm not alone  
here?


If that's the case, is there a best practice for going from value  
objects delivered from a service, to first class, intelligent model  
citizens in the domain? One thing I've found confusing about the  
Cairngorm approach is that models and value objects seem to be  
synonymous.


You thoughts?

Cheers,
Lach


On 05/12/2006, at 11:13 PM, Alex Uhlmann wrote:

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. …


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.  ;)

RE: [flexcoders] Re: Cairngorm's Anaemic Domain Model

[Alex Uhlmann]

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: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Lachlan Cotter
Sent: 05 December 2006 11:30
To: flexcoders@yahoogroups.com
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.


 


att8d3e9.gif
Description: att8d3e9.gif