tag:robotlegs.tenderapp.com,2009-10-18:/discussions/robotlegs-2/7248-robotlegs-activerecord-patternRobotlegs: Discussion 2013-10-15T12:28:57Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/293882712013-10-15T09:31:08Z2013-10-15T09:31:08ZRobotlegs + ActiveRecord Pattern<div><p>Hi Paulo,</p>
<p>I have only a theoretical knowledge of the ActiveRecord Pattern.
I agree with the author of these articles: <a href=
"http://www.mehdi-khalili.com/orm-anti-patterns-series">http://www.mehdi-khalili.com/orm-anti-patterns-series</a>,
especially regarding the violation of the SRP.<br>
I've seen examples where the Views hold all the logic for accessing
a server and binding the results to models, that were also part of
the View...From an MVCS point of view, that's not a good
practice:)<br>
On the other side, Robotlegs, as a framework, doesn't care about
how you use it, i.e. whether you follow an MVCS or an MVP pattern,
or none at all. With Robotlegs 2 you could even inject anything you
want into your views.</p>
<p>Due to my lack of practical experience with ActiveRecord and to
your rather broad question, I can't really tell you how to organize
your classes. I also don't know how much you already know about
MVCS, but if you already understand the roles of each layer, you
can easily detect the parts in your code that need to be extracted
into separate classes.<br>
Just in case you're not familiar with the MVCS roles:</p>
<ul>
<li>Services+Models+VOs =responsible for retrieving data,
manipulating data, persisting data structures</li>
<li>Service = gatekeeper to the outside world, data supplier, data
source. Services should encapsulate logic for storing data to
external data storage and/or retrieving data from external data
sources (persistent data storage: Server, File system…), and
informing other actors about the results.</li>
<li>Model = deals with data, data modeler, responsible for
manipulating the application’s states. A Model should
encapsulate all the logic responsible for maintaining the integrity
of the data, for manipulating the data, and for informing other
actors of changes to the data (through events or signals).</li>
<li>VO = data carrier class to shuttle typed data across tiers</li>
<li>Controller = Events+Commands = application logic =
application’s behavior= use cases</li>
<li>Commands act upon Models and Services, usually in response to
user interactions with the application</li>
<li>View = user interface</li>
<li>Mediator = intermediate, intermediary between application and
View, wiring the Views to the shared event dispatcher.</li>
</ul>
<p>=> Services are the intermediaries between an application and
the outside world; Mediators are intermediaries between the
application and the user interface.</p>
<blockquote>
<p>It ´s a good time to turn the views loselly coupled from
our models,</p>
</blockquote>
<p>I fully agree with that:)</p>
<p>Now, if you need more help with this, just provide more info,
and we might find an appropriate solution.</p>
<p>In the mean time I'll move the discussion from Suggestions to
Robotlegs 2.</p>
<p>Cheers,<br>
Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/293882712013-10-15T11:45:30Z2013-10-15T11:45:30ZRobotlegs + ActiveRecord Pattern<div><p>Hi Ondina,</p>
<p>Thanks for your reply.<br>
That link was actually very useful. Actually made ​​me
understand better why I ended up with spaghetti code :)<br>
But I get the idea that the productivity achieved with ActiveRecord
Pattern is too obvious to ignore, even violating some principles of
OO design as SRP. If I can wrap this functionality in Service Layer
through an interface, I can get the best of both worlds,
abstracting the application of using ActiveRecord .. i think.<br>
I'm still at the stage of learning RobotLegs framework, and trying
to figure out how to glue all these parts. When I actually start
writing some code, I'll post my experience with it.<br>
Best regards.</p></div>paulo.campostag:robotlegs.tenderapp.com,2009-10-18:Comment/293882712013-10-15T12:28:56Z2013-10-15T12:28:56ZRobotlegs + ActiveRecord Pattern<div><blockquote>
<p>But I get the idea that the productivity achieved with
ActiveRecord Pattern is too obvious to ignore, even violating some
principles of OO design as SRP.</p>
</blockquote>
<p>Yes, theory is one thing; putting it into practice is another. I
think, what really matters, is finding the best compromise between
the "best practices" and the requirements of a specific project.
Design patterns are there to support a project, not vice versa
;)</p>
<blockquote>
<p>If I can wrap this functionality in Service Layer through an
interface, I can get the best of both worlds, abstracting the
application of using ActiveRecord .. i think.</p>
</blockquote>
<p>That's a good idea!</p>
<blockquote>
<p>When I actually start writing some code, I'll post my experience
with it.</p>
</blockquote>
<p>Yes, please do so.</p>
<p>I'm going to mark this discussion as resolved. Don't hesitate to
re-open it, if need be, or to start new discussions, if you have
other questions.</p>
<p>Ondina</p></div>Ondina D.F.