<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: PureMVC Tutorial - Flex, PureMVC, Jabber and XIFF 3: Part 5 - Model &#38; Proxy</title>
	<atom:link href="http://www.actionscriptdeveloper.co.uk/puremvc-tutorial-flex-puremvc-jabber-and-xiff-3-part-5-model-proxy/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.actionscriptdeveloper.co.uk/puremvc-tutorial-flex-puremvc-jabber-and-xiff-3-part-5-model-proxy/</link>
	<description>Professional and reliable UK based Actionscript development</description>
	<pubDate>Tue, 09 Mar 2010 21:40:14 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: devdave</title>
		<link>http://www.actionscriptdeveloper.co.uk/puremvc-tutorial-flex-puremvc-jabber-and-xiff-3-part-5-model-proxy/#comment-247</link>
		<dc:creator>devdave</dc:creator>
		<pubDate>Tue, 31 Mar 2009 08:55:50 +0000</pubDate>
		<guid isPermaLink="false">http://www.actionscriptdeveloper.co.uk/puremvc-tutorial-flex-puremvc-jabber-and-xiff-3-part-5-model-proxy/#comment-247</guid>
		<description>Hey Will,

There aren't any hard and fast rules to this - its really up to you how you split up the proxies.  However, here are some things that I personally think about:

o If a proxy contains methods that operate on a specific logical concept then seperate it out.  For example, in an address book application all the methods to do with contact CRUD might be in ContactProxy and all the methods to do with import/export might be in ImportExportProxy.
o I often put things that access different remote services into their own proxies.  For example, if our Jabber application also got information about users via a web service these methods might well be in their own proxy.
o Sometimes there is a fairly direct map between the services in your proxy, delegate and backend so I try to keep these synchronised.  For example, if I have a large AMFPHP application I'll have UserProxy only calling methods in UserMethods.php, etc.  This means that the way the backend is compartmentalised sometimes dictates the way the proxies are split.
o Its often good to try and get all similar functionality into a single proxy for purposes of re-use.  I always try to split them up in such a way that if I decide that I want to use 'UserProxy' in a new application it contains everything to do with users.

But, when you get right down to it, split the proxies however you feel most comfortable - they are there for your convenience!

Hope that helps,

Dave</description>
		<content:encoded><![CDATA[<p>Hey Will,</p>
<p>There aren&#8217;t any hard and fast rules to this - its really up to you how you split up the proxies.  However, here are some things that I personally think about:</p>
<p>o If a proxy contains methods that operate on a specific logical concept then seperate it out.  For example, in an address book application all the methods to do with contact CRUD might be in ContactProxy and all the methods to do with import/export might be in ImportExportProxy.<br />
o I often put things that access different remote services into their own proxies.  For example, if our Jabber application also got information about users via a web service these methods might well be in their own proxy.<br />
o Sometimes there is a fairly direct map between the services in your proxy, delegate and backend so I try to keep these synchronised.  For example, if I have a large AMFPHP application I&#8217;ll have UserProxy only calling methods in UserMethods.php, etc.  This means that the way the backend is compartmentalised sometimes dictates the way the proxies are split.<br />
o Its often good to try and get all similar functionality into a single proxy for purposes of re-use.  I always try to split them up in such a way that if I decide that I want to use &#8216;UserProxy&#8217; in a new application it contains everything to do with users.</p>
<p>But, when you get right down to it, split the proxies however you feel most comfortable - they are there for your convenience!</p>
<p>Hope that helps,</p>
<p>Dave</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Will</title>
		<link>http://www.actionscriptdeveloper.co.uk/puremvc-tutorial-flex-puremvc-jabber-and-xiff-3-part-5-model-proxy/#comment-241</link>
		<dc:creator>Will</dc:creator>
		<pubDate>Wed, 25 Mar 2009 17:40:10 +0000</pubDate>
		<guid isPermaLink="false">http://www.actionscriptdeveloper.co.uk/puremvc-tutorial-flex-puremvc-jabber-and-xiff-3-part-5-model-proxy/#comment-241</guid>
		<description>I'm confused about proxies. I want to continue to use MVC outside of the XMPP/chat features of my application. So for my non-xmpp functions, should I create a proxy for these? Or when do you decide you need to create another proxy?</description>
		<content:encoded><![CDATA[<p>I&#8217;m confused about proxies. I want to continue to use MVC outside of the XMPP/chat features of my application. So for my non-xmpp functions, should I create a proxy for these? Or when do you decide you need to create another proxy?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
