tag:robotlegs.tenderapp.com,2009-10-18:/discussions/robotlegs-2/1349-what-is-the-place-for-business-logic-command-or-model-itselfRobotlegs: Discussion 2013-04-09T16:24:53Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/262408052013-04-05T13:18:34Z2013-04-05T13:22:50ZWhat is the place for business logic ? Command or Model itself ?<div><p>A game that generates points, using the level the user has
completed and the timeleft has got a long algorithm . Where should
this algorithm be kept ? inside command or in the model ?</p>
<p>So, should i have a command..</p>
<pre>
<code> eventCommandMap
.map(GameEvent.ON_LEVEL_COMPLETE
.toCommand(CalculatePointsCommand,gameEvent); // gameEvent.level , gameEvent.timeLeft</code>
</pre>
<p>with the algorithm inside the CalculatePointsCommand ?</p>
<p>or</p>
<p>this command should just call the calculatePoints() , inside the
model ??</p>
<p>Had doubts since, the logic algorithm is very long for some
reason. So, i am not sure if "command" is the right place ? As i
think i remember somewhere in the forum somewhere ,that the command
should only "direct" things, and should not be overloaded by
calculations!</p>
<p>However, i also use similar small validations ( using the state
of application from model) inside command... so again i think that
command should be the right place to put the algorithm there!</p>
<p>Please suggest. Thanks</p>
<p>V.</p></div>vishwas.gagranitag:robotlegs.tenderapp.com,2009-10-18:Comment/262408052013-04-05T14:39:02Z2013-04-05T14:39:02ZWhat is the place for business logic ? Command or Model itself ?<div><p>The first question to ask is whether it is view logic or
not.</p>
<p>But, since you’ve already decided that the outcome of your
calculation is application data – probably needed by other
actors in your app too – the best place for this kind of
logic would be a Model, in my opinion.</p>
<p>Cheers,<br>
Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/262408052013-04-05T14:46:54Z2013-04-05T14:46:54ZWhat is the place for business logic ? Command or Model itself ?<div><p>Just wanted to add that if it feels dirty to put that logic into
a model, because it's all related to one specific calculation,
other options would be to create a calculation-specific model or a
simple helper class used by the model which encapsulates the
calculation as a black box.</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/262408052013-04-07T07:27:31Z2013-04-07T07:27:31ZWhat is the place for business logic ? Command or Model itself ?<div><p>I am not sure, if it's a view logic.<br>
But it displays the points on the Result Screen View finally. So
probably it's a view logic then!</p>
<p>Should not be command used for calculation then ?<br>
I thought "Model" should only contain the "data" part. It shouldnot
have anything to do with calculations. Afterall, it just represents
the state of the whole application ( data state, or view state
etc)</p>
<p>So, why i thought, command should be used for such logic, is the
practice i follow as follows :</p>
<p>1) Use the Command for logic ( Something similar to running a
DOS command on the terminal, which can run successfully or fail. If
successful, model is updated which in turn updates the view. If
not, command , dispatches an "unsuccessful" event )</p>
<p>2) Start validations and if else loops ( using all the available
information inside data-model and view-model )</p>
<p>3) The output of all these calculations ( throug if -else etc ),
will change the information inside the model .<br>
4) The model function is then called<br>
5) The model then dispatches update events to the view.</p></div>vishwas.gagranitag:robotlegs.tenderapp.com,2009-10-18:Comment/262408052013-04-08T09:59:08Z2013-04-08T09:59:08ZWhat is the place for business logic ? Command or Model itself ?<div><blockquote>
<p>I thought "Model" should only contain the "data" part. It
shouldnot have anything to do with calculations. Afterall, it just
represents the state of the whole application ( data state, or view
state etc)</p>
</blockquote>
<p>A Model (rl-MVCS) can <em>hold</em> and <em>manipulate</em>
application’s states / data.</p>
<p>The main reason for using a Model would be portability,
re-use.<br>
Views, Models and Services are the actors in your application that
are the most likely to be reused and/or shared in or between
different applications (rl or non-rl).<br>
Applications are dependent on Models, not the other way around. The
application can expose the domain data to the users and let them
interact with it. The Model should be – as far as possible
– framework-agnostic and you should be able to easily extract
it into a library.<br>
Whether is a Model or a Helper class, it doesn’t matter as
long the logic is encapsulated and re-usable.</p>
<p>The way you described the workflow in your last post, makes me
think that you could indeed use a Helper class, as creynders
suggested. Let’s call it PointsCalculator. You either access
it from your GameModel or from your command. The command updates
GameModel with the results from PointsCalculator, then either
GameModel or the command dispatches an event with the updated
data.</p>
<p>If you encapsulate the calculation logic inside a
PointsCalculator, you can also use it as a hook in other
scenarios.</p>
<blockquote>
<p>Start validations and if else loops ( using all the available
information inside data-model and view-model )</p>
</blockquote>
<p>What do you mean by data model and view model?</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/262408052013-04-08T13:30:15Z2013-04-08T13:30:15ZWhat is the place for business logic ? Command or Model itself ?<div><p>ok thanks,<br>
.. helper class is a good option then. I actually never thought of
portability and reuse of model class! Will try thinking it that way
from now :p</p>
<p>View model.. might be i am using a wrong terminology ( just made
it on my own to help myself understand ).. but i try to describe
it..<br>
I experimented using a multiplayer game with robotlegs recently.
So, there the "views" have to be synchronized on all the clients
equally. The way, a "Model" ( data model) stores the data state of
application, similarly i used "view-model" to store the
"view-state" of the application. The view state can be data
representing position of windows, or anything by which same view
can be drawn.<br>
So, for example, if a playerView (sprite) is going from point ( x=
100, y = 100 ) to point ( x= 300, y=400 ) , the playerViewModel
contains this data of the player regularly synchronizing it to all
the other clients.</p>
<p>A simple example is a form containing a textfield, combo-box and
a button.<br>
When i said data model , it's data to be filled inside textfield,
and combobox .<br>
When i said view model, it's information about the type ofcontrols
( textfield,combobox, button etc) ,the position of textfield,
combobox, button and everything else that describes the view</p>
<p>V.</p></div>vishwas.gagranitag:robotlegs.tenderapp.com,2009-10-18:Comment/262408052013-04-08T15:26:37Z2013-04-08T15:26:37ZWhat is the place for business logic ? Command or Model itself ?<div><blockquote>
<p>I actually never thought of portability and reuse of model
class! Will try thinking it that way from now :p</p>
</blockquote>
<p>Yes, even if you’ll never reuse your Views, Models or
Services, having their portability in mind when you create your
classes, helps you<br>
-encapsulate them better,</p>
<p>-let them be as independent(framework-agnostic) as possible,</p>
<p>-define their roles easier,</p>
<p>-create them by following the “good” principles like
SRP, DRY, and you know, all the other OOP practices ;)</p>
<blockquote>
<p>View model.. might be i am using a wrong terminology ( just made
it on my own to help myself understand ).. but i try to describe
it..</p>
</blockquote>
<p>Ah, ok, I understand now.</p>
<p>In your case if the view is PlayerView, I’d avoid naming
it PlayerViewModel. You either name it simply PlayerModel, or if,
as it seems, you’re using 2 models for the same view,<br>
I’d use PlayerLayoutModel instead of PlayerViewModel, if that
model is used to store only PlayerView’s information about
position, size, colors…If it has a more general use, like in
storing layout info for more views, you could give it a more
generic name, LayoutModel or ComponentsDesignModel. I admit words
like layout , design, or styles can also be ambiguous, but I think
they describe a little better the role of such a model than
PlayerViewModel. Anyway, choose a name that is descriptive enough.
It’s not at all easy to find good names for classes and
packages.<br>
It might be helpful to imagine yourself working with others, even
if you don’t have a team, and to try to look at the names of
classes and packages with their eyes. Would they understand the
roles of your classes just by looking at them, or are lots of
explanations required?</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/262408052013-04-09T05:11:56Z2013-04-09T05:11:56ZWhat is the place for business logic ? Command or Model itself ?<div><p>ok. Got it! :)<br>
Thanks for the useful and enlightening inputs.</p></div>vishwas.gagranitag:robotlegs.tenderapp.com,2009-10-18:Comment/262408052013-04-09T16:24:52Z2013-04-09T16:24:52ZWhat is the place for business logic ? Command or Model itself ?<div><p>Hehe, no problem!</p></div>Ondina D.F.