RemoteObject/Data Getter question.

[CDHBookingEdge]

This is kind of both a design question and functional question at the same time.

Now let's take the design of a normally large program. By that I mean not a single view single purpose type program. In it you're going to have a number of views, dialogs and other such things. These will all quite possibly need to get data for use in their interaction. And this data quite possibly exists one "database" that has numerous tables and such.

The ways I keep seeing things presented in samples and such, the RemoteObject is "defined" and "declared" in one MXML file. But in the scenario presented above isn't there the need for the RemoteObject to exist as separate object or (dare I say) class itself? And really isn't it totally independent of any of the "Views" being represented by the MXML code?
Otherwise you've got one MXML that has a RemoteObject in it and other MXML files are referring to that "global object".

Isn't that so? And isn't that kinda bad programming?

For example, if we take a look in livedocs as far as RemoteObject, and then we look at the example (http://livedocs.macromedia.com/flex/2/langref/mx/rpc/remoting/mxml/RemoteObject.html#includeExamplesSummary) they give, we can note a thing or two. First off they define it in this MXML file, and they do so as follows:

<mx:RemoteObject id="RO" destination="MyRemoteObjectDest"
fault="Alert.show(event.fault.faultstring), 'Error'">
<mx:method name="GetQuote">
<mx:arguments>
<symbol>{stockSymbol.text}</symbol>
</mx:arguments>
</mx:method>
</mx:RemoteObject>

Now really most projects of any size will quite possibly be made up of any number of MXML files, any number of views dialogs and other such "visual objects". And they may all need to talk to this one "controlling" RemoteObject, this overall "data getter" that's in charge of talking to the data that exists on the server. And RemoteObject is not a "visual object".
So I quess I'm kind of saying that instead of making RemoteObject an MXML declaration, shouldn't it be a separate ActionScript class? I mean really what they are doing in the above is creating a "class" of type RemoteObject, and they are putting in information providing what the methods are that it is able to call.

Is my "thesis" correct or am I just being silly here? And if I am correct, does anyone know of any examples of defining a RemoteObject in ActionScript?

Thanks in advance,
Christopher

[Assertnfailure]

Well, .as classes are always the way to go if you want to keep your code stricter and more formal. mxml is good for layouts, rapid prototyping, and providing easy access to the code thats liable to change. For data management and server interaction, I'd usually stick with .as

[CDHBookingEdge]

Thanks for that input Assert. So really what you're saying is: (and you stated it more appropriately that I could even think to do) "For data management and server interaction, I'd usually stick with .as"

These things are present on the client but they are not strictly part of the Presentation tier. Am I right in my take of your response?

[Assertnfailure]

I'm not really sure what you're asking...but if its "Is this functionality strictly for mxml?" then I'd have to say no.

Pretty much anything you are trying to accomplish with mxml can be accomplished with provided as classes instead. It's just a matter of which is most appropriate. Sure you can probably write a whole flex 2 application in AS, but that defeats the purpose of mxml. What tier you intend to place logic into goes back to the common OOP practices you can apply to other languages.

[CDHBookingEdge]

No, I don't think I was saying that, as far as the strictly for MXML. I suppose I was saying essentially that even tiers need further segregation. And I just kinda found that interesting. And I think I misread your statement earlier and on second reading I can see the more "definite" statement(s) you made. Thanks for the input Assert.

Christopher

Christopher