tag:robotlegs.tenderapp.com,2009-10-18:/discussions/problems/483-new-to-mvc-new-to-robotlegs-please-helpRobotlegs: Discussion 2012-03-08T09:20:24Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/138212172012-02-19T23:46:22Z2012-02-19T23:46:23ZNew to MVC, new to Robotlegs, please help<div><p>If possible, would anyone be willing to walk me through setting
up my project to work with RobotLegs? I don't need hand holding. I
know how to code, and I do it well. I just feel like once I
understand the concept of MVC, it will literally be an ENORMOUS
weight off of my shoulders.</p></div>Stevetag:robotlegs.tenderapp.com,2009-10-18:Comment/138212172012-02-20T08:29:15Z2012-02-20T08:29:50ZNew to MVC, new to Robotlegs, please help<div><p>It's one of those concepts that only starts to make sense when
you're dealing with larger applications and/or when working on the
same application with several developers, that's why it's a bit
hard to grasp when reading tutorials. The tutorials are kept small
and easy in order to clearly communicate the concept itself, but
obviously the motivation for using the methodology remains a bit
vague then.</p>
<p>Compare it with tasks, if you've got 3 tasks that need to be
done on a certain date, you won't feel the need to have some kind
of task organization, but if you have to deal with dozens of
different tasks, with various due dates you'll start using
todo-lists. Then when you start working with a team of people and
you need to prioritize and sequence tasks, you realize simple
todo-lists won't suffice and you'll end up with applying SCRUM for
instance (it obviously deals with more than task management, but it
is one of the core parts of the methodology)</p>
<p>The same applies to MVC. <strong>It's benefits are absolutely
not restricted to large-scale, team-based development, but they
become most obvious in such situations</strong>.</p>
<p>Let's say you need to make a web application that loads some
data in a xml file, lets the user do some operations on that data
and saves the users edits in a SharedObject.<br>
Fine. It's a small application, you can develop it pretty fast and
there's no need to start thinking about using MVC or other patterns
for structuring your components (not talking about UI components
here, just cogs in the machine).<br>
The application is a huge success and your client is extremely
satisfied, they ask you to change the application because they'll
be setting up a back end with which the xml file can be manipulated
by them, in fact no, they want to use a database instead of the
file. And since it's 2012 they definitely need an iphone app as
well.<br>
You'll start working on the web application and since the
deadline's not just tight, but completely insane chances are you'll
be modifying it to reflect the use case changes, make a copy of the
entire project to create the iphone app and again simply making the
iOS required changes in that project directly.<br>
Now repeat this five times. The client keeps on asking
modifications. expansions etc. These can be UI related changes, but
even complete backend architecture swaps, going from REST to SOAP
for instance.<br>
If you didn't structure your project using MVC, you'll be in a
world of pain. No, you'll be in a world of pain anyway, but had you
used MVC from the start you'd notice that some things would've been
less painful:</p>
<ul>
<li>
<p>95% of the code for the web application and the iphone app will
be the same, but instead of saving the user data to a Shared Object
or through a web service, you'd be using a local DB for instance.
Due to the separation of concerns as promoted with MVC (and even
more specifically with RL) you'd notice that the only thing
different in the web app and the iphone app would've been a single
service class. Without MVC chances are pretty high you'll be making
modifications in a bunch of classes.</p>
</li>
<li>
<p>The same applies to the UI for instance. Again, the heart of the
application is the same, only the way it's presented to the user is
different. Due to separation of your app into the various tiers
you'll notice that changing the UI for the iphone app, will only
have an impact on view classes and you'll spent a tremendous amount
of time less of searching through your code and finding out where
to change what.</p>
</li>
<li>
<p>w/o MVC 95% of both apps would still be the same, but the
differences would've been scattered in various files, here and
there some lines, with MVC the differences will be in using
different classes, ie the changes are more compact and
overseeable.</p>
</li>
</ul>
<p>All in all using MVC makes your code more structured and far
more flexible to accomodate change in size, platform etc. etc.</p>
<p>There's more, but I've run out of time, hope to come back to
this soon.</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/138212172012-02-20T09:26:15Z2012-02-20T09:26:15ZNew to MVC, new to Robotlegs, please help<div><p>Almost two years ago I wrote a paper for school, called "Is MVC
for me?". Reading it now, there are a lot of ways it could be
improved, but I think it might still be interesting anyway. It
initially focuses on PureMVC, a framework Robotlegs borrows a lot
of its concepts from, and makes a (rather small) comparison with
Robotlegs:</p>
<p><a href=
"http://abeldebeer.nl/documents/AbeldeBeer_MVC_29-06-2010.pdf">http://abeldebeer.nl/documents/AbeldeBeer_MVC_29-06-2010.pdf</a></p></div>Abel de Beertag:robotlegs.tenderapp.com,2009-10-18:Comment/138212172012-02-20T15:10:12Z2012-02-20T15:10:12ZNew to MVC, new to Robotlegs, please help<div><p>In addition to the excellent information Camille and Abel
already<br>
gave, you might be interested in picking up Stray's book on
Robotlegs:<br>
<a href=
"http://www.amazon.com/ActionScript-Developers-Guide-Robotlegs-Hooks/dp/1449308902/">
http://www.amazon.com/ActionScript-Developers-Guide-Robotlegs-Hooks...</a></p>
<p>It's a great introduction into both the framework as well as the
goals<br>
behind it.</p></div>Till Schneidereit