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:

void buySkill(PlayerCharacter playerCharacter, Skill skill);
void changeName();
void changeRole();
void restatCharacter();
void addCharacterToGame();
void createNewCharacter();
PlayerCharacter getPlayerCharacter();
List<PlayerCharacter> getPlayersCharacter(Player player);
List<PlayerCharacter> getAllCharacters();

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.

  • How do you think this is deviating from MVC?
    – pdr
    Sep 17, 2012 at 12:33
  • 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! Sep 17, 2012 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.
    – pdr
    Sep 17, 2012 at 12:55
  • @pdr I am...I didn't know there was a difference.... Sep 17, 2012 at 13:09
  • Wait. Just saw your edit. What kind of app is this? Web or Windows or something else?
    – pdr
    Sep 17, 2012 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.

Methods to a controller class would look more like:

void Engine::run(Configuration c);
void Engine::run(Configuration c, Logger l);

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.

I hope that answers your question.

  • After reading 3-4 times, and wondering why I can't see your name next to your icon, I think this is a really helpful response. Thanks! Sep 17, 2012 at 13:34
  • @Pureferret, not sure why you can't see my name. Anyway, glad I could help.
    – Neil
    Sep 19, 2012 at 6:57
  • Oddly it's back now. I blame IE. Sep 19, 2012 at 7:47

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

So your example is definitely not the Controller.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.