You have some good points. Here are my responses to your arguments…

1. High Coupling. As for your arguments, first when I say high coupling, I am referring to coupling between the front-end and back-end. If there are multiple front-end solutions that use the same CakePHP backend, then for every change that is made to the database an overhaul will ripple out to the front-end implementations. For Flex applications, this means that you need to rebuild (and redistribute) the SWF. In AIR applications, this is even more problematic as it would require an update to be pushed out to every installed AIR application.

If the modeling due to the database change were handled on the backend, this wouldn’t have to happen. In my opinion, this is not a good thing. However, the same can be said if your front-end application has several different back-end implementations. I think this is less frequently used, hence my reasoning for doing it on the back-end.

2. Less of a chance of refactoring. I agree with you that schema changes in the database will more often than not require a change to the front-end. However, what if you decide that the schema you are using for the backend is inefficient for some reason. Maybe you are using too many joins, or your back-end is overly taxed? This might be a reason to refactor that database schema which would require you to change the front-end and rebuild. If all of this were handled on the back-end, we wouldn’t have to deal with the front-end in these cases.

3. SWF Size. True, SWF size isn’t that big of a deal since the object modeling classes wouldn’t add too much overhead, but I feel it is a matter of principle that you should always try to keep the size down.

4. Utilize the server. You can always add server space and computer power as you see fit. This part can be perfectly scalable (according to your budget). The client’s computer, on the other hand, you have no control over. This is probably not that big of a deal because the computing power required to model objects is probably negligible.

As a side note, I would be interested in hearing your ideas for Fake. If this is something you could share, let me know.

Thanks for your thoughts.

There are some examples and also test cases for how the as3 conversion is done via the ResultSet class.

A few of us hang out in #fake-as3 on irc.freenode.net

Bottom line, Coupling is no fun and has to be dealt with. You are not avoiding it by using a DTO.

As far as the server goes, You hit the nail on the head. Conversion is light and therefore will have very little if any noticeable affect on the client. Whereas, if you do it on the server, for a couple hundred users, I am sure you will notice it. Of course, you could cache, but that just creates more work and potential for problems.

For me the biggest thing is having the same controllers for amf, xml, json, html, without the need for extra logic.

As the developer of CakeAMF, I made this decision a while ago. To compensate on the front-end I have been working on a sister project called Fake, which makes working with Cake objects in a native Flex environment trivial.

In fact, Fake uses a single model as the VO and RO which to me simplifies development in Flex even further.

Now onto your pros:
“lack of high coupling” – you are dreaming here. There is still a high degree of coupling no matter what you do.
“less of a chance of refactoring” – Any time you make a schema change you are going to need to update both ends. Really no way around it if you want to maintain strong typing.
“decrease swf size” – we are talking bytes here, not MB. Flex used to add 400kb and we still used it so really this pro is weak.
“utilize the server” – ALWAYS a con. simple as that.
“maintains style” – you can still have that if your resultset class formats things the way you want.
“maintains flex standard” – the most valid pro, but really is that a good standard we should even follow?
“take adavantage of object mapping” – you can still have this, as we do in Fake.

The Cons are both valid and are actually big Pros that outweigh the Cons when you decide to push the job onto the front end.

Anyway, its a good question for discussion. I hope i have added to it.

Good Luck.