In my personal project I have tried to stick to MVC, but I've also been made aware that sticking to MVC too tightly can be a bad thing as it makes writing awkward and forces the flow of the program in odd ways (i.e. some simple functions can be performed by something that normally wouldn't, and avoid MVC related overheads).

So I'm beginning to feel justified in this compromise:

I have some 'manager programs' that 'own' data and have some way to manipulate it, as such I think they'd count as both part of the model, and part of the control, and to me this feels more natural than keepingthem separate. For instance: One of my Managers is the PlayerCharacterManager that has these methods:

I hope the mothod names are transparent enough that they don't all need explaining.

I've called it a manager because it will help manage all of the PlayerCharacter 'model' objects the code creates, and create and keep a map of these. I may also get it to store other information in the future.

I plan to have another two similar classes for this sort of control, but I will orchestrate when and how this happens, and what to do with the returned data via a pure controller class. This splitting up control between informed managers and the controller, as opposed to operating just through a controller seems like it will simplify my code and make it flow more.

My question is, is this a dangerous choice, in terms of making the code harder to follow/test/fix? Is this somethign established as good or bad or neutral? I oculdn't find anything similar except the idea of Actors but that's not quite why I'm trying to do.

Edit: Perhaps an example is needed; I'm using the Controller to update the view and access the data, so when I click the 'Add new character to a player button' it'll call methods in the controller that then go and tell the PlayerCharacterManager class to create a new character instance, it'll call the PlayerManager class to add that new character to the player-character map, and then it'll add this information to the database, and tell the view to update any GUIs effected. That is the sort of 'control sequence' I'm hoping to create with these manager classes.

Because in MVC, to my knowledge you have one controller that has no state and 99% of the methods, and your model has all the states/data and just getters/setters to access (private) data fields. I'm happy if the answer is "This is still within the bounds of MVC" I'm just not sure that it is!
–
PureferretSep 17 '12 at 12:44

I think you're confusing the domain model (the M of MVC) with the data model. The domain model contains all the logic of your domain. The data model just contains data.
–
pdrSep 17 '12 at 12:55

@pdr I am...I didn't know there was a difference....
–
PureferretSep 17 '12 at 13:09

Wait. Just saw your edit. What kind of app is this? Web or Windows or something else?
–
pdrSep 17 '12 at 14:18

2 Answers
2

The difference between Model and Controller can be subtle, but it boils down to this: Who is in charge here?

If you make a class which manages all aspects of a PlayerCharacter, that isn't necessarily a Controller. Somebody calls this manager, say, a class called Engine which calls all respective classes to draw, perform calculations, requests changes to made to players (PlayerCharacter gets called here presumably). Engine is the Controller, not PlayerCharacter.

Most often, parameters to control classes are configurations, altering generic attributes but saying nothing about how that method is to behave. Alternatively, model classes do very specific tasks and should be transparent as to what it does. Their parameters are important because they directly influence the behavior of the method (getPlayersCharacter for instance). Since all your methods listed above are rather transparent, you can conclude that you are writing a model class, not a controller.

Notice that since it does a variety of things, it is very generic in nature. Ideally, it is a relatively short method which relies on many higher-level model classes to do its operations, but sometimes it is necessary to have more than one Controller class to manage various aspects. However the principle is the same. In those classes, you would see little difference in method naming. Just be wary to include generic controller methods in an otherwise model class. That is the essence of MVC.

It is in general dangerous to mix things that have proven good to be split, as is also the case of mixing application control and domain model.

But it is not the case of your example. You 'player manager' class (I would call it Team or Game, but I don't know the others), is perfect part of the Model.

As was already mentioned, you have probably too 'database-driven' view. Try to forget about data(base)'s central role - it is just the persistence engine, nothing more. It is not the centre, it is a service.

Model contains all the logic of your application (logic, not data; that it in fact must contain (that is, manipulate and return) some data, is just the derived from the fact it contains the logic). One thing that Model may depend upon is a persistency service, eg. database.

So Model is primarily API, not data. So your example is a perfect fit into the Model.

View is, hopefully, clear -- this is the one that presents parts of the Model to the user.

Controller (or other things in MV* class of patterns, like Presenter in MVP or View Model in MVVM) are the hardest to catch. Classical Controller in MVC is the one that reacts to (user) events and manipulates the Model (consequently, the view updates).