   MVC questions
  OK, I'm getting started with MVC and I've got some questions.I have abstract classes for Entity (model), Entity2D (view) and EntityController (controller) and bunch of implementations for them (no deep inheritance trees and they're pretty generic classes). Entities contain all the logic and have no direct references to either view or controller. Models send info to views through listeners, like ThrusterListener, CannonListener etc. Controllers are now mainly just a simple interface to model.In the book I'm reading, there's an example of MVC that uses Java's Swing in which the view stores a reference to both model and controller, but I kind of fail to see point in including a controller reference in my Entity2D. The Entity2D already receives the position, angle etc. directly from the model - either through events or by getters. I understand that it fits in the Swing example, as the view in it has buttons etc. and these UI components have ActionListeners registered to them. But (at least for now) I dont see any reason why I'd want to send actions to model from view..?Now the most important question is that how to put these all together, for example would it be a good idea to have a separate factory for models, views and controllers? I also have SpaceShip, that can have any number of Thrusters and Cannons. The Thrusters and Cannons have views and controllers too, as they are entities just like SpaceShip. However, I'm a quite confused of how to create/manage these components. Should I put a list of ThrusterControllers and CannonControllers into SpaceShipController? And should SpaceShip2D have a list of Thruster2Ds and Cannon2Ds?   
  Unfortunately, this reply won't be a direct response to your questions. But, in the past I've been a very big proponent of MVC, particularly in the context of games, and generally in any "interactive" model.I'd like to say first of all that I think it's most important to think of MVC as a logical separation of responsibilities in your engine. In other words, given a schematic of your overall engine architecture you should be able to say something akin to "everything on the left is controller, everything on the right is view, and everything in the middle is model."This doesn't seem to be the way that MVC is usually presented. MVC is most often presented as a direct pattern to apply to individual classes. Like in your situtation where you have an EntityModel, an EntityView and an EntityController class (names changed for clarity). This style has also been directly built into several APIs and languages, so it's no suprise to me that it must be the pervailing perspective on MVC. But as I mentioned above, my view is a bit nebulous in that regard.I haven't written anything definitive on MVC (even though I've proposed to in several threads on the subject), mainly because the more I think about it the higher I push it up the abstraction ladder. It begins to make me think that it's wrong (or maybe redundant?) to apply MVC at the class level.In your example, if I was designing the system (and I am designing one vageuly similar), I would have an Entity class that represents your game object in the Model portion of your engine. Separately, I'd have what's generally referred to as the "presentation layer," which could be a collection of classes or whatever, that would pull information from the Model portion of your engine as necessary to "present" the game to the player. This presentation layer would be the view component. Finally, you'd have a section of your engine that provides the Controller functionality, forwarding inputs into the Model section.Now, how is all of that implemented? I'm not sure. But, I'm not sure that it actually matters in relation to MVC. Yes, you want good encapsulation and such, but that applies everywhere. In practice, what you probably won't have is a distinct Model class with corresponding View classes and Controller classes.But then again, you might... I've also toyed with the idea that MVC can and should be applied at several different levels of abstraction, from engine design down to class design. This still remains theory for myself as I've not actually implemented a system like this, though.;Quote:I'd like to say first of all that I think it's most important to think of MVC as a logical separation of responsibilities in your engine.Yeah that's actually the main reason I am getting into MVC, as I got tired to the mess I had before, when one class had way too many jobs to do. In addition to MVC, I also separated the loading/parsing to external Resource-classses, so that each entity (or whatever object) has it's loading encapsulated in own class. Of course, the class count has increased a lot but it ain't a problem as the classes live in their own packages anyway. And they're in nicely manageable chunks now.I came up with something like this - actually I already had the higher level separation of GameState/GameModel/GameScreen done, but I hadn't thought I could just directly glue it together with the "entity-level", this actually seems to be very logical way to manage things out.Game renders & ticks the StateManager which in turn does the same for GameState(s)GamePlayState extends GameState - creates GamePlayModel and GamePlayScreen - manages GamePlayModel and GamePlayScreen (render & tick) - creates EntityControllers - manages EntityControllers - provides a clean (and possibly "decorated") interface to GameModel for usersGamePlayModel extends GameModel - creates Entities - manages Entities - all logic lives hereGamePlayScreen extends GameScreen - has all UI components - creates Entity2Ds - renders the UI, GamePlayModel & Entity2DsI don't have enough insight to think about the reusability in practice but I think it should work pretty nicely.I think I can build a (real-time) game/mission editor easily now, just by decorating the GamePlayState, GamePlayModel and GamePlayScreen.Quote:I haven't written anything definitive on MVC (even though I've proposed to in several threads on the subject), mainly because the more I think about it the higher I push it up the abstraction ladder. It begins to make me think that it's wrong (or maybe redundant?) to apply MVC at the class level.I don't think it's redundant to use MVC for class-level (not 100% sure what you mean with class-level), and I think it fits nicely for the entities as things get lot easier to understand and control with the clean separation of jobs. And I think MVC acts as a kind of guide, so I have to think less when doing new things.All this said, I've still little practical experience with MVC... and the big picture is still forming. But the more I think of this, the more i'm liking MVC.Thanks for your thoughts.. I'd rate you up - but seems I already had :), I've actually read the some of the older threads too and they were very helpful.   