Home → Robotlegs 2 →

What is the place for business logic ? Command or Model itself ?

• Edit

vishwas.gagrani

05 Apr, 2013 01:18 PM

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 ?

So, should i have a command..

                      eventCommandMap
        .map(GameEvent.ON_LEVEL_COMPLETE
        .toCommand(CalculatePointsCommand,gameEvent);   // gameEvent.level , gameEvent.timeLeft

with the algorithm inside the CalculatePointsCommand ?

or

this command should just call the calculatePoints() , inside the model ??

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!

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!

Please suggest. Thanks

V.

1. Support Staff 1 Posted by Ondina D.F. on 05 Apr, 2013 02:39 PM

   

   The first question to ask is whether it is view logic or not.

   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.

   Cheers,
   Ondina

   • Edit

2. Support Staff 2 Posted by creynders on 05 Apr, 2013 02:46 PM

   

   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.

   • Edit

3. 3 Posted by vishwas.gagrani on 07 Apr, 2013 07:27 AM

   

   I am not sure, if it's a view logic.
   But it displays the points on the Result Screen View finally. So probably it's a view logic then!

   Should not be command used for calculation then ?
   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)

   So, why i thought, command should be used for such logic, is the practice i follow as follows :

   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 )

   2) Start validations and if else loops ( using all the available information inside data-model and view-model )

   3) The output of all these calculations ( throug if -else etc ), will change the information inside the model .
   4) The model function is then called
   5) The model then dispatches update events to the view.

   • Edit

4. Support Staff 4 Posted by Ondina D.F. on 08 Apr, 2013 09:59 AM

   

   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)

   A Model (rl-MVCS) can hold and manipulate application’s states / data.

   The main reason for using a Model would be portability, re-use.
   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).
   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.
   Whether is a Model or a Helper class, it doesn’t matter as long the logic is encapsulated and re-usable.

   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.

   If you encapsulate the calculation logic inside a PointsCalculator, you can also use it as a hook in other scenarios.

   Start validations and if else loops ( using all the available information inside data-model and view-model )

   What do you mean by data model and view model?

   • Edit

5. 5 Posted by vishwas.gagrani on 08 Apr, 2013 01:30 PM

   

   ok thanks,
   .. 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

   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..
   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.
   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.

   A simple example is a form containing a textfield, combo-box and a button.
   When i said data model , it's data to be filled inside textfield, and combobox .
   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

   V.

   • Edit

6. Support Staff 6 Posted by Ondina D.F. on 08 Apr, 2013 03:26 PM

   

   I actually never thought of portability and reuse of model class! Will try thinking it that way from now :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
   -encapsulate them better,

   -let them be as independent(framework-agnostic) as possible,

   -define their roles easier,

   -create them by following the “good” principles like SRP, DRY, and you know, all the other OOP practices ;)

   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..

   Ah, ok, I understand now.

   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,
   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.
   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?

   • Edit

7. 7 Posted by vishwas.gagrani on 09 Apr, 2013 05:11 AM

   

   ok. Got it! :)
   Thanks for the useful and enlightening inputs.

   • Edit

8. Support Staff 8 Posted by Ondina D.F. on 09 Apr, 2013 04:24 PM

   

   Hehe, no problem!

   • Edit

9. Ondina D.F. closed this discussion on 09 Apr, 2013 04:24 PM.