How to write reusable business logic in MVC models

Question

my problem is that we try to use a MVC (PHP) framework. After discussing a lot think that MVC is very good, but I'm missing the possibility to write reusable model-(application)logic. So, I'm not sure if we have the right approach to implement our software in a MVC framework.

First I´ll describe the non-MVC, oo-approach which we use at the moment.

For example - we are working on some browser games (yes that's our profession). Imagine we have an player object. We use this player object very often. We have some different pages where you can buy thinks, so you need to make "money" transactions on the players "bank-account" or imagine you can do fights against other players. We have several fight-scripts, and these scripts take 2 or more player objects (it depends on the type of battle ie. clan battle, player vs. player battle...).

So, we have several pages (and controllers) with different battle-logic. But each of this controllers use the player-object to calculate all the attributes and items a player has and which damage and defence a player will do.

so, how can we reuse the logic in the player object in case of a MVC Model? it would be bad to duplicate all the necessary logic in the different fight-controllers and -models.

I think the "gold-transaction"-logic would be a good example to give you some more detail information. you need the transact-function in case of a fight, if you win against an other player and loot some of his gold, you need the transaction function in case of buying some stuff and you need the transact-function in case of spending some gold to the players guild...

So, I would say it would be a bad approach to define all these functions in one player model! I can say you these player model would be very big (actually we have the problem that our player-class is really huge - its a god class)

do you think there is a MVC-style solution for this problem?

Answer 1

I would say you put the code where it makes the most sense, and where you would not need to duplicate it someplace else.

If there is some operation that always needs a Player object, but might be used across different Controllers, the Player class would be the logical place to put it. On the other hand, if a bit of logic only needs to be done in the context of a certain Controller, and involves potentially other classes, it perhaps should be in the controller - or perhaps in some other class, too.

If you are having trouble figuring out where the logic should go, perhaps it's because your functions are not granular and reusable enough as they are. There are certainly aspects of MVC that force you to think a little bit more about the separation of concerns and keeping things DRY more than a 'plain' OOP approach... so you might end up breaking up currently coded operations that are in a single function now into multiple functions on different classes to get the right code in the right places.

For example - and these are not at all specific suggestions, but just a random possible thought process - maybe the process of transferring 'gold' between players needs to be broken down into more granular processes. The player class may do the basic task of changing the balance, but then the controller(s) may do specific parts of the process, such as verifying to/from whom gold is being transferred and why.