MVC Application Framework
by Demolishun · in General Discussion · 10/20/2012 (5:18 pm) · 8 replies
I am in the middle of writing an application and am looking at ways to better structure the code to be better structured and maintainable. I have been doing some research on the MVC design and have found huge differences of opinion on how it is supposed to work. As I think through this process I am confronted with a couple of different cases where I can see dividing up responsibilities in a different ways makes sense. Here are a couple of examples:
So with these two examples you can see I am still struggling with the concept of Business Logic (Controller) and the Domain Logic (Model). In the game app I can see where having the game logic as part of the model as making sense. However, I am not sure if this should not be in the controller business logic. I don't think Torque is a good example of MVC as I don't think it was designed that way. If it was, then please explain how it fits that model.
Does anyone else have some good examples or experience with MVC to comment on this? I really want to understand this as I see the potential for swapping out the View part as being a desirable thing for games. I would consider the View portion to be things like sound, video, user input, etc. I am almost looking at the T3D client as one giant View object. The server is more of the Model.
- Web Page App
- --View is code that produces the actual web page downloaded by client, output.
- --Model is your database and functions specific to maintaining database integrity. The domain logic.
- --Controller is the code that takes input from the model or view and decides what to do with this input. The so called business logic.
- Game App
- --View is the graphics, sound, etc.
- --Model is the object data, logic to control the data, and possibly game specific logic (this is where I get confused).
- --Controller is the same as the web page app example. However, I see value of having more logic in model especially for different game types.
So with these two examples you can see I am still struggling with the concept of Business Logic (Controller) and the Domain Logic (Model). In the game app I can see where having the game logic as part of the model as making sense. However, I am not sure if this should not be in the controller business logic. I don't think Torque is a good example of MVC as I don't think it was designed that way. If it was, then please explain how it fits that model.
Does anyone else have some good examples or experience with MVC to comment on this? I really want to understand this as I see the potential for swapping out the View part as being a desirable thing for games. I would consider the View portion to be things like sound, video, user input, etc. I am almost looking at the T3D client as one giant View object. The server is more of the Model.
About the author
I love programming, I love programming things that go click, whirr, boom. For organized T3D Links visit: http://demolishun.com/?page_id=67
#2
I have worked on enterprise applications using MVC years ago. Your point of conflict, is the same I had at the time I started with this design pattern.
There are a few things to have in mind from the begining.
First, that design patterns come from the corporate world, where sometimes app frameworks are shared by a given company accross continents, where thousands of people with totally different entry points to the system, and dozens (in some cases houndreds) of developers of all sorts, work on different parts and angles of the same system.
This is the single most important thing to understand about design patterns, to avoid ending up as an inmate in Arkham Asylum: they come from very specific principles, that evolved into what today we know as patterns, usually for using on totally different contexts.
Also, the most widely known or most used design patterns, come from the Java world, where most of this concepts are already there by default, and terms that are mere concepts for others, are concrete implementations already working in the language itself.
Another important point, is that often patterns require extra time on design and implementation, under the premise that you will recover that investment in the future, be it on time, or in the posibilities of the framework in general. This may not be the case for every development.
So, always you look into a patern, use it as inspiration, rather than something like a concrete implementation plan.
In the case of MVC the main idea behind, as you well said, is to separate the data from the logic, and the logic from the client. This way, you end up with an environment where each layer is totally abstracted from the other.
So your coders in Singapur, only need an API to code a new iOS client for the employees there, while the employees in Canda use a web client, and the central office in US use a Windows form client with different access levels. In time, all what the logic layer does with data IO is through another API on top the system objects, as it is handled by a persistence manager, with storage servers on different places across Middle East.
So after that introduction-rant: if the app is a game, how (or why) do you implement MVC, will depend on a few things.
First of all, MVC assumes an always online system, so if your game is downloadable single player, MVC would mean a lot of effort, in a direction of unlikely benefit.
One case, may be the Model+Controller in one layer, and view on other. In my current contract, Im working on a sort of mixed system, with M+C in one layer, plus another layer of the Model remotely, and separated View.
I think this is the more likely scheme for todays ecosystem: multiple Views for multiple target plataforms, with the core of the player data stored locally, and still plenty of info on the cloud (for multiple purposes that vary from full backups to simple online scoreboards).
Today, is also hard to separate where the game ends. You have the client on the player plataform(s). You will likely have singleplayer experiences that require the whole logic to be there. Still, multiplayer nowadays implied a master server. But soon that master server will become authoritative for more than player scores. You will want to create events, send updates, handle other data. You soon will find that maybe is easier to tweak the game variables from your server, rather than with clumsy patches...
There is a line that is blurry nowadays, and only time will tell if MVC will be really useful for games, or simply become obsolete for us, sooner than the benefits we may expect from it appear.
10/22/2012 (9:40 am)
Hello Frank.I have worked on enterprise applications using MVC years ago. Your point of conflict, is the same I had at the time I started with this design pattern.
There are a few things to have in mind from the begining.
First, that design patterns come from the corporate world, where sometimes app frameworks are shared by a given company accross continents, where thousands of people with totally different entry points to the system, and dozens (in some cases houndreds) of developers of all sorts, work on different parts and angles of the same system.
This is the single most important thing to understand about design patterns, to avoid ending up as an inmate in Arkham Asylum: they come from very specific principles, that evolved into what today we know as patterns, usually for using on totally different contexts.
Also, the most widely known or most used design patterns, come from the Java world, where most of this concepts are already there by default, and terms that are mere concepts for others, are concrete implementations already working in the language itself.
Another important point, is that often patterns require extra time on design and implementation, under the premise that you will recover that investment in the future, be it on time, or in the posibilities of the framework in general. This may not be the case for every development.
So, always you look into a patern, use it as inspiration, rather than something like a concrete implementation plan.
In the case of MVC the main idea behind, as you well said, is to separate the data from the logic, and the logic from the client. This way, you end up with an environment where each layer is totally abstracted from the other.
So your coders in Singapur, only need an API to code a new iOS client for the employees there, while the employees in Canda use a web client, and the central office in US use a Windows form client with different access levels. In time, all what the logic layer does with data IO is through another API on top the system objects, as it is handled by a persistence manager, with storage servers on different places across Middle East.
So after that introduction-rant: if the app is a game, how (or why) do you implement MVC, will depend on a few things.
First of all, MVC assumes an always online system, so if your game is downloadable single player, MVC would mean a lot of effort, in a direction of unlikely benefit.
One case, may be the Model+Controller in one layer, and view on other. In my current contract, Im working on a sort of mixed system, with M+C in one layer, plus another layer of the Model remotely, and separated View.
I think this is the more likely scheme for todays ecosystem: multiple Views for multiple target plataforms, with the core of the player data stored locally, and still plenty of info on the cloud (for multiple purposes that vary from full backups to simple online scoreboards).
Today, is also hard to separate where the game ends. You have the client on the player plataform(s). You will likely have singleplayer experiences that require the whole logic to be there. Still, multiplayer nowadays implied a master server. But soon that master server will become authoritative for more than player scores. You will want to create events, send updates, handle other data. You soon will find that maybe is easier to tweak the game variables from your server, rather than with clumsy patches...
There is a line that is blurry nowadays, and only time will tell if MVC will be really useful for games, or simply become obsolete for us, sooner than the benefits we may expect from it appear.
#3
The model holds two things: the classes diagram, and the data, which will return as one thing to the controller.
The controller, holds the bussiness logic. Gets input from the player, and queries data from the model, process it, and sends it back to the view and/or the model.
The view, is a mere visual representation of the data, for human IO.
Torque use some of this concepts actually. All you see visually, is a simulation of what in reality is happening on the server, so conceptually, is near.
What would be required is an extra separation of the game data, which is rather hard on this case, as the networking model is very pervasive, and central to the handling of the data.
10/22/2012 (9:59 am)
Btw, I never commented on what you are struggling now.The model holds two things: the classes diagram, and the data, which will return as one thing to the controller.
The controller, holds the bussiness logic. Gets input from the player, and queries data from the model, process it, and sends it back to the view and/or the model.
The view, is a mere visual representation of the data, for human IO.
Torque use some of this concepts actually. All you see visually, is a simulation of what in reality is happening on the server, so conceptually, is near.
What would be required is an extra separation of the game data, which is rather hard on this case, as the networking model is very pervasive, and central to the handling of the data.
#4
The reason I am looking into patterns at all is because it seems my GUI based apps tend to sprawl a bit and do not have a clean organization. Usually I end up forming the data around the GUI framework which makes the code hopelessly tied to that framework. So the MVC and MVP patterns have obvious benefits for helping to organize the data, code, and interaction.
The example I am playing with is really cool. It uses interactors reduce the clutter in the presenter and help abstract the interface to the view. I am developing a robot control program and my first run at the program is really messy. I didn't want to maintain that mess in the future. So I am redoing the approach. I think once I get a handle on MVP for machine control I will work on applying it to game design. Like you indicated, I am not applying MVP to apply MVP. I am applying MVP to solve an organization and maintainability problem.
10/22/2012 (11:48 am)
You are right, struggle with identifying the separation is difficult. I am playing with the MVP pattern now as it seems to be a good variation on the MVC pattern. I read a really good article by some machine automation experts and their development of the Presenter First method for using the MVP pattern. The reason I am looking into patterns at all is because it seems my GUI based apps tend to sprawl a bit and do not have a clean organization. Usually I end up forming the data around the GUI framework which makes the code hopelessly tied to that framework. So the MVC and MVP patterns have obvious benefits for helping to organize the data, code, and interaction.
The example I am playing with is really cool. It uses interactors reduce the clutter in the presenter and help abstract the interface to the view. I am developing a robot control program and my first run at the program is really messy. I didn't want to maintain that mess in the future. So I am redoing the approach. I think once I get a handle on MVP for machine control I will work on applying it to game design. Like you indicated, I am not applying MVP to apply MVP. I am applying MVP to solve an organization and maintainability problem.
#5
10/22/2012 (12:12 pm)
I have not studied (or work) with MVP, so let me know how it goes. Good luck with project!
#6
richnewman.wordpress.com/2008/02/26/model-view-presenter-variations-on-the-basic...
www.martinfowler.com/eaaDev/PassiveScreen.html
To me MVP makes more sense for what I am trying to accomplish.
Here is the example I am playing with:
wiki.wxpython.org/ModelViewPresenter
It has a link to the industrial control app whitepaper which outlines the Presenter First method of using MVP. It is a good writeup.
The simple structure on the third link helped me to understand the organization. It really made a lot of sense for the interactor to separate out the callbacks. So in a way it is even abstracting the callback mechanism. So in theory this could be anything like networking even. Very slick. Then it shows how to write unit tests which is a main driver for MVP. The thinner the View is the less it needs to be tested.
In a game design where the engine is the view it can be complete separate from the game logic. So it could be tested without the engine! Obviously with T3D this is not going to be completely practical as the design is very interwoven. However it is giving me ideas of how I can strategize a large project like an MMO which is very IT driven. MMOs must be scalable and that is what this design pattern is supposed to help solve. I think there is value here for smaller projects as well. I even started wondering if I can design the GUI to be event driven with intermediate callback definitions. It will be interesting.
Thanks for the feedback Novack. You have given me much to think about.
10/22/2012 (12:25 pm)
Yeah, it is interesting:richnewman.wordpress.com/2008/02/26/model-view-presenter-variations-on-the-basic...
www.martinfowler.com/eaaDev/PassiveScreen.html
To me MVP makes more sense for what I am trying to accomplish.
Here is the example I am playing with:
wiki.wxpython.org/ModelViewPresenter
It has a link to the industrial control app whitepaper which outlines the Presenter First method of using MVP. It is a good writeup.
The simple structure on the third link helped me to understand the organization. It really made a lot of sense for the interactor to separate out the callbacks. So in a way it is even abstracting the callback mechanism. So in theory this could be anything like networking even. Very slick. Then it shows how to write unit tests which is a main driver for MVP. The thinner the View is the less it needs to be tested.
In a game design where the engine is the view it can be complete separate from the game logic. So it could be tested without the engine! Obviously with T3D this is not going to be completely practical as the design is very interwoven. However it is giving me ideas of how I can strategize a large project like an MMO which is very IT driven. MMOs must be scalable and that is what this design pattern is supposed to help solve. I think there is value here for smaller projects as well. I even started wondering if I can design the GUI to be event driven with intermediate callback definitions. It will be interesting.
Thanks for the feedback Novack. You have given me much to think about.
#7
I am still putting it together, but I have an app partially started using MVP and I am already seeing why this is a good idea. It is forcing me to think about the roles of the different pieces of the program. At first this was a little tough. As I work through this I am finding that it is helping me layout the app better. I am treating the Model as a data store and it led to some interesting things.
Since the model cannot know about the view or the presenter (my take on MVP) it must have complete standalone operation. So I set about using a regular config file as the data store. You know, the regular Windows style config files. This turned out to be a really good idea since I already have libraries for handling this. I then came up with the concept of events. These events must be able to be changed, deleted, updated, saved, and reloaded. I designed 3 event types: timed, response, and script. They are specific to the task so don't think to hard about the meaning of the events. I was able to encapsulate these functions and presented the presenter with one object call Data. This object will store all other objects so the Presenter can access the data. Included in this Data object is the Events object. This object hides all details of the event management.
What is so interesting about this is the separation is leading to natural encapsulation which is very much desired. It just helps you categorize these in your head. The best part is with little changes I can reuse the storage class handling the config files very easily. I am already thinking about using that one piece in another app I am writing. So even though I have just started using this method I am already finding reuse for the code. Usually for something like this I would have tied this to a callback on a GUI object. Generally there would be code mixed in to handle GUI updates and the like. Well since I have purposely avoided that I can just use this code pretty much as is without having to strip that stuff out.
Once I get to a certain point I may do a blog on this. The subject of my test app is controlling a MMORPG from an external app. So it is a fun topic to begin with. I think I found a way to allow user side scripting without compromising the program itself as well. This will make it so the user can customize the program to suit their needs. It should be a good test case for MVP design pattern.
10/23/2012 (7:41 pm)
Hey Novack,I am still putting it together, but I have an app partially started using MVP and I am already seeing why this is a good idea. It is forcing me to think about the roles of the different pieces of the program. At first this was a little tough. As I work through this I am finding that it is helping me layout the app better. I am treating the Model as a data store and it led to some interesting things.
Since the model cannot know about the view or the presenter (my take on MVP) it must have complete standalone operation. So I set about using a regular config file as the data store. You know, the regular Windows style config files. This turned out to be a really good idea since I already have libraries for handling this. I then came up with the concept of events. These events must be able to be changed, deleted, updated, saved, and reloaded. I designed 3 event types: timed, response, and script. They are specific to the task so don't think to hard about the meaning of the events. I was able to encapsulate these functions and presented the presenter with one object call Data. This object will store all other objects so the Presenter can access the data. Included in this Data object is the Events object. This object hides all details of the event management.
What is so interesting about this is the separation is leading to natural encapsulation which is very much desired. It just helps you categorize these in your head. The best part is with little changes I can reuse the storage class handling the config files very easily. I am already thinking about using that one piece in another app I am writing. So even though I have just started using this method I am already finding reuse for the code. Usually for something like this I would have tied this to a callback on a GUI object. Generally there would be code mixed in to handle GUI updates and the like. Well since I have purposely avoided that I can just use this code pretty much as is without having to strip that stuff out.
Once I get to a certain point I may do a blog on this. The subject of my test app is controlling a MMORPG from an external app. So it is a fun topic to begin with. I think I found a way to allow user side scripting without compromising the program itself as well. This will make it so the user can customize the program to suit their needs. It should be a good test case for MVP design pattern.
#8
Will look foward to read your blog.
10/24/2012 (6:19 am)
Haha excellent progress Frank, thanks for the news. Indeed, can be tough at the start, but you soon find the benefits of that design.Will look foward to read your blog.
Torque Owner Demolishun
DemolishunConsulting Rocks!
http://wiki.wxpython.org/ModelViewController
http://wiki.wxpython.org/ModelViewPresenter
These led me here:
http://www.martinfowler.com/eaaDev/uiArchs.html
What is fascinating me on this subject is that to reduce the coupling of the logic from the view. This allows the system to be testing without the view layer if taken far enough. It also minimizes the potential of the view layer from causing issues. So it sounds like it allows you to design in such a way to be able to write more bug free code.
I think, taken this far for something like T3D you could essentially treat the engine as a view layer and lightly couple the game logic with the engine. Then the game logic can be tested outside the engine. So the engine and game logic can be developed independently. This implies you could also move to a different view layer (another engine) as your requirements dictate.