I brought up the MVC design paradigm a few months ago and had a phpBB developer state that he thought it best to leave MVC for the desktop apps and stick with what phpBB currently has for the web apps.
Now, I myself have built my own MVC framework and have recoded various parts of my site to work with it. I must say, though there's extra work involved with maintaining more files, it does make things easier to fix in the long run, and also opens up new possibilities when one considers that the views and models can be adapted. Say you have a forums topic view which normally outputs a standard topic page such as you are reading right now. If you want to later add a printer-view mode, then that's as simple as adding a new view: the controller and model stay the same.
Or say if your data source changes from a database to an XML file. Without MVC, you'd have to rewrite a bunch of files to remove the SQL queries and change the logic. With an MVC model, then just the model changes, since the rest of the app's logic doesn't have to deal with how the data is getting to it, just that the data does get to it.
There's more advantages than just these, of course, but I'll save those for later.
MVC - Yay or nay?
Forum rules
Please do not post support questions regarding installing, updating, or upgrading phpBB 3.3.x. If you need support for phpBB 3.3.x please visit the 3.3.x Support Forum on phpbb.com.
If you have questions regarding writing extensions please post in Extension Writers Discussion to receive proper guidance from our staff and community.
Please do not post support questions regarding installing, updating, or upgrading phpBB 3.3.x. If you need support for phpBB 3.3.x please visit the 3.3.x Support Forum on phpbb.com.
If you have questions regarding writing extensions please post in Extension Writers Discussion to receive proper guidance from our staff and community.
Re: MVC - Yay or nay?
Things like database abstraction are in place regardless of the architectural pattern. As to MVC: MVC, as the very first pattern, goes back to the very first OO GUI applications and is to this day much better suited for persistent applications. That does not mean desktop applications per se, but rather applications that are stateful, java EE web applications are an example as well. If you consider matters, you will find that 3.0 implements a - somewhat crude - MVC.
For script based web applications, where the application is very small and only active for fractions of seconds, but runs concurrently several times this architecture has a lot of drawbacks. Bootstrapping the MVC is quite costly -- fine for a monolithic app, but in php that would mean every pageload. Thus, the advantages can't really be played out in a web app. Moreover, consider that a web app's type of user interaction, requests and responses, is very different from a GUI.
The other downside a MVC introduces is a certain rigidity. As we want to realize a plugin-based architecture, we have to consider how plugins interact. We could use plain dependency injection with a MVC, using an appropriate view etc, but the thing is that plugin, even core, modules will require to crosscut all three layers. That's why we are aiming for a queue-oriented architecture, which is more in-line with the requirements of a modern web application and agile development. The advantages of MVC do not vanish because of this. Even in a queue oriented architecture, you will find database abstraction - much more abstract than in 3.0 - and queue elements solely responsible for generating output. It should be noted that this is often called MVC in the php world, without being MVC in the strict sense.
We hope to get the first elements into working order soon
For script based web applications, where the application is very small and only active for fractions of seconds, but runs concurrently several times this architecture has a lot of drawbacks. Bootstrapping the MVC is quite costly -- fine for a monolithic app, but in php that would mean every pageload. Thus, the advantages can't really be played out in a web app. Moreover, consider that a web app's type of user interaction, requests and responses, is very different from a GUI.
The other downside a MVC introduces is a certain rigidity. As we want to realize a plugin-based architecture, we have to consider how plugins interact. We could use plain dependency injection with a MVC, using an appropriate view etc, but the thing is that plugin, even core, modules will require to crosscut all three layers. That's why we are aiming for a queue-oriented architecture, which is more in-line with the requirements of a modern web application and agile development. The advantages of MVC do not vanish because of this. Even in a queue oriented architecture, you will find database abstraction - much more abstract than in 3.0 - and queue elements solely responsible for generating output. It should be noted that this is often called MVC in the php world, without being MVC in the strict sense.
We hope to get the first elements into working order soon
No support via PM.
Trust me, I'm a doctor.
Trust me, I'm a doctor.
Re: MVC - Yay or nay?
It must have been you.
Re: MVC - Yay or nay?
I agree with Henry we shouldn't unecessarily restrict ourselves. I'm pretty sure that we'll end up with something going in the direction of what most PHP MVC architectures do anyway simply by trying to build a clean architecture for the whole app.
- Techie-Micheal
- Registered User
- Posts: 566
- Joined: Sun Oct 14, 2001 12:11 am
Re: MVC - Yay or nay?
Yay on MVC for things like large article-based websites, but I'm not sure it makes sense for things like discussion boards.