MVC approach - easier or unnecessarily complicated for web developers using C5?
Permalink
I've had a few weeks to play around with Concrete5 and although I still don't quite get everything as to how C5 does things (the underlying code is very poorly commented, complicated, and incredibly hard to follow and understand) I have come to know enough to wonder if the MVC (Model, View, Controller) approach used by C5 really hinders more than helps web developers.
Now I know that the same approach is used by CodeIgnitor, PHPCake, and some other frameworks and software but...quite frankly...the only thing that matters to me is whether the MVC approach makes my job easier or tougher with respect to using a piece of software like Concrete5 to build client sites. Not how many other pieces of software have jumped on the MVC wagon.
And my experience of Concrete5 so far has not left me with a very high regard to the MVC approach. If anything it has gotten in my way instead of helping me.
A case in point is a form block that I have been playing with.
The action for the form normally goes into the action statement of the FORM HTML tag - pretty straight forward. Not so with the MVC approach. It gets put into a file called a controller.php in a whole different directory and is called as a function in a class.
That just makes things more complicated and I ask myself...did such a convoluted way of indicating the action for a FORM make my life easier or tougher? Does it help me write better code? Nope. Not at all.
It complicates the writing of code for me where I do not see any benefit at all to splitting it up that way. None whatsoever.
Now I grant you that I am relatively new to this MVC approach so maybe I will change my mind in time but as of right now it just seems like something a software engineer came up with that has only made things more complicated (as engineers are sometimes prone to do).
What, pray tell, is the benefit to this approach? I mean practically.
Give me the nuts and bolts of it in practice. Not the theory. How has it helped you write better, faster code?
Has it really, I mean really helped you or has it made life more difficult as a web developer?
I am just curious.
Anybody?
Carlos
Now I know that the same approach is used by CodeIgnitor, PHPCake, and some other frameworks and software but...quite frankly...the only thing that matters to me is whether the MVC approach makes my job easier or tougher with respect to using a piece of software like Concrete5 to build client sites. Not how many other pieces of software have jumped on the MVC wagon.
And my experience of Concrete5 so far has not left me with a very high regard to the MVC approach. If anything it has gotten in my way instead of helping me.
A case in point is a form block that I have been playing with.
The action for the form normally goes into the action statement of the FORM HTML tag - pretty straight forward. Not so with the MVC approach. It gets put into a file called a controller.php in a whole different directory and is called as a function in a class.
That just makes things more complicated and I ask myself...did such a convoluted way of indicating the action for a FORM make my life easier or tougher? Does it help me write better code? Nope. Not at all.
It complicates the writing of code for me where I do not see any benefit at all to splitting it up that way. None whatsoever.
Now I grant you that I am relatively new to this MVC approach so maybe I will change my mind in time but as of right now it just seems like something a software engineer came up with that has only made things more complicated (as engineers are sometimes prone to do).
What, pray tell, is the benefit to this approach? I mean practically.
Give me the nuts and bolts of it in practice. Not the theory. How has it helped you write better, faster code?
Has it really, I mean really helped you or has it made life more difficult as a web developer?
I am just curious.
Anybody?
Carlos
Thanks for your reply Scott.
I was hoping to get some practical examples of how MVC has helped you (or anyone) code better and with less hassles but I understand what you are saying.
Maybe it will indeed grow on me.
For now I've decided to use Concrete5 for my web development projects so like it or not I do have to at least try and work with it.
Still...it never hurts to question the value of an approach, any approach, if in the initial trying it doesn't make my work easier.
Going along with the masses of software programmers who, from what you say, seem to be moving in the direction of MVC does not make it the best thing to use.
The real test is in whether it really makes things better/easier in real life programming and web site creation.
Incidentally with the form controller I mentioned as an example...the code there is so closely tied to the form that it's completely unusable by any other form so in this case using a controller was a complete waste of time and unnecessarily complicated the code when contrasted with a the same form coded as a standard HTML/PHP type of way with the action in the FORM action attribute and the HTML and PHP rolled into the same file.
Carlos
I was hoping to get some practical examples of how MVC has helped you (or anyone) code better and with less hassles but I understand what you are saying.
Maybe it will indeed grow on me.
For now I've decided to use Concrete5 for my web development projects so like it or not I do have to at least try and work with it.
Still...it never hurts to question the value of an approach, any approach, if in the initial trying it doesn't make my work easier.
Going along with the masses of software programmers who, from what you say, seem to be moving in the direction of MVC does not make it the best thing to use.
The real test is in whether it really makes things better/easier in real life programming and web site creation.
Incidentally with the form controller I mentioned as an example...the code there is so closely tied to the form that it's completely unusable by any other form so in this case using a controller was a complete waste of time and unnecessarily complicated the code when contrasted with a the same form coded as a standard HTML/PHP type of way with the action in the FORM action attribute and the HTML and PHP rolled into the same file.
Carlos
well that is i am guessing block view to block controller meshed stuff, that isn't a super awesome example of how concrete5 doesn't try to tell you what to do.
The primary purpose of MVC is to improve the maintainability of your code by separating application logic from presentation. A nice secondary benefit is that it facilitates communication between different coders because it is a standard way of structuring things so it's easier to hunt things down when you're bugfixing or adding new features.
That being said, Concrete5's implementation of MVC is *very* incomplete and inconsistent. The form block is probably the most blatant example of this, as the entire presentation of the form is tied up in that controller method that creates a table! Other examples abound, such as tons of inline SQL statements for data handling throughout the core code instead of utilizing a model layer to encapsulate data handling functions.
In my experience, MVC is a means to an end -- the important part is keeping your presentation separate from your application logic, and you don't necessarily need MVC to achieve that -- it's just one of many ways. For example, look at the "Form Tableless Layout" template I made -- I put a whole bunch of php up at the top of that file, and then down below is very minimal php interspersed into the HTML. This is by no means "MVC", but it accomplishes the goal of separating the logic from the presentation. The only code in the "presentation" (the HTML) is simple echoing of variables and a couple of simple loops. It's not ideal, but it's better than the way it was.
The only place I really see MVC providing a benefit to C5 developers is in the fact that when you're making a block, you don't need to manually shuffle data back and forth and explicitly save it to the database -- with a few exceptions, the variables are just magically available in add.php and edit.php by virtue of the fact that the fields exist in the database schema. Yes, this is limited to the "primary" table for the block, and you still have to handle other tables yourself, but for 80% of blocks this is all that is needed.
Other than that, yeah it's not really used to its fullest potential in C5. Would be really nice if it was, but the PHP world seems to be much more concerned with pragmatism than code purity. The best way to learn MVC I've found is to learn Ruby On Rails. It is an amazing system with excellent tutorials and documentation. I don't do as much Rails coding as I used to, but the things I learned from it improved my programming skills immensely, which then filtered back down to everything else I do, including PHP/C5.
-Jordan
EDIT: If you're interested in learning Rails, I'd specifically recommend the amazing book "Agile Web Development with Rails", and the incredible (and free) websitehttp://ruby.railstutorial.org/ruby-on-rails-tutorial-book...
That being said, Concrete5's implementation of MVC is *very* incomplete and inconsistent. The form block is probably the most blatant example of this, as the entire presentation of the form is tied up in that controller method that creates a table! Other examples abound, such as tons of inline SQL statements for data handling throughout the core code instead of utilizing a model layer to encapsulate data handling functions.
In my experience, MVC is a means to an end -- the important part is keeping your presentation separate from your application logic, and you don't necessarily need MVC to achieve that -- it's just one of many ways. For example, look at the "Form Tableless Layout" template I made -- I put a whole bunch of php up at the top of that file, and then down below is very minimal php interspersed into the HTML. This is by no means "MVC", but it accomplishes the goal of separating the logic from the presentation. The only code in the "presentation" (the HTML) is simple echoing of variables and a couple of simple loops. It's not ideal, but it's better than the way it was.
The only place I really see MVC providing a benefit to C5 developers is in the fact that when you're making a block, you don't need to manually shuffle data back and forth and explicitly save it to the database -- with a few exceptions, the variables are just magically available in add.php and edit.php by virtue of the fact that the fields exist in the database schema. Yes, this is limited to the "primary" table for the block, and you still have to handle other tables yourself, but for 80% of blocks this is all that is needed.
Other than that, yeah it's not really used to its fullest potential in C5. Would be really nice if it was, but the PHP world seems to be much more concerned with pragmatism than code purity. The best way to learn MVC I've found is to learn Ruby On Rails. It is an amazing system with excellent tutorials and documentation. I don't do as much Rails coding as I used to, but the things I learned from it improved my programming skills immensely, which then filtered back down to everything else I do, including PHP/C5.
-Jordan
EDIT: If you're interested in learning Rails, I'd specifically recommend the amazing book "Agile Web Development with Rails", and the incredible (and free) websitehttp://ruby.railstutorial.org/ruby-on-rails-tutorial-book...
How would you propose the custom form that you've written work? The processing code has to live somewhere that it can be executed before the page renders, so it can't exactly live right above the form tag (although it actually could.)
I see these kind of arguments, and I think it boils down to developers who are new to a system wanting to do the right thing and use the new system (the MVC stuff), which is laudable, but without being as familiar with the system as they are with their particular way of doing things. This leads to a frustrating barrier of entry, which I sympathize with.
The thing to remember is that we're not really keeping you from using any other method of development. You're free to put logic in single pages or views and not separate them MVC-style (indeed, you'll see certain pages in the core that do just that. :-> )
I also think it doesn't necessarily help that the Custom/External Form block isn't really the easiest thing to pick up and learn in concrete5. I really think the block system is pretty darn elegant for those who take the time to learn it, and the single pages -> controller setup, while initially it might be difficult to wrap your head around, really does a nice way to encouraging separation of code and content, separating reusable templates from those that perform just one function, and allowing concrete5 editing/permissions control over these scripts. Your mileage may vary, of course.
I see these kind of arguments, and I think it boils down to developers who are new to a system wanting to do the right thing and use the new system (the MVC stuff), which is laudable, but without being as familiar with the system as they are with their particular way of doing things. This leads to a frustrating barrier of entry, which I sympathize with.
The thing to remember is that we're not really keeping you from using any other method of development. You're free to put logic in single pages or views and not separate them MVC-style (indeed, you'll see certain pages in the core that do just that. :-> )
I also think it doesn't necessarily help that the Custom/External Form block isn't really the easiest thing to pick up and learn in concrete5. I really think the block system is pretty darn elegant for those who take the time to learn it, and the single pages -> controller setup, while initially it might be difficult to wrap your head around, really does a nice way to encouraging separation of code and content, separating reusable templates from those that perform just one function, and allowing concrete5 editing/permissions control over these scripts. Your mileage may vary, of course.
Thanks for the input you all. Much appreciated.
It's nice to get a different perspective on things as a way of helping me maintain some balance in my decidedly subjective views of MVC so far.
One reason that I am sticking with Concrete5 for now (among others) is that it does indeed give me the flexibility to use a more pragmatic approach to adding functionality in whatever way seems best to me without straightjacketing me into doing things it's way and only it's way (as WordPress is more inclined to do). That's a very good point Andrew.
Carlos
It's nice to get a different perspective on things as a way of helping me maintain some balance in my decidedly subjective views of MVC so far.
One reason that I am sticking with Concrete5 for now (among others) is that it does indeed give me the flexibility to use a more pragmatic approach to adding functionality in whatever way seems best to me without straightjacketing me into doing things it's way and only it's way (as WordPress is more inclined to do). That's a very good point Andrew.
Carlos
Hi Carlos,
Just to clarify one of your observations...
> The action for the form normally goes into the action statement of the
> FORM HTML tag - pretty straight forward. Not so with the MVC approach.
Actually, that's not true. In C5, the "action" attribute of the "form" element contains the URL to which the form is submitted, just like any form.
> It gets put into a file called a controller.php in a whole different directory
> and is called as a function in a class.
What you're referring to is the LOGIC that PROCESSES the form once it's submitted -- not the value of the action attribute itself.
> What, pray tell, is the benefit to this approach? I mean practically.
It maintains a clean separation of the presentation (UI) from the logic. The external form block is not the ideal example of this, however, as it is intended specifically for "special purpose" (custom) forms which are generally assumed to have a single unique presentation.
For most other blocks, however, you might have several different ways in which you want the block to appear. In other words, the mark-up (view) might be entirely different for two different instances of the SAME block type. Thus, by keeping the bock's implementation logic separate from the view, you can change the look of the block without altering any of its logic. This is done by choosing "Custom Template" from the popup menu for the block when the page is in edit mode.
-Steve
Just to clarify one of your observations...
> The action for the form normally goes into the action statement of the
> FORM HTML tag - pretty straight forward. Not so with the MVC approach.
Actually, that's not true. In C5, the "action" attribute of the "form" element contains the URL to which the form is submitted, just like any form.
> It gets put into a file called a controller.php in a whole different directory
> and is called as a function in a class.
What you're referring to is the LOGIC that PROCESSES the form once it's submitted -- not the value of the action attribute itself.
> What, pray tell, is the benefit to this approach? I mean practically.
It maintains a clean separation of the presentation (UI) from the logic. The external form block is not the ideal example of this, however, as it is intended specifically for "special purpose" (custom) forms which are generally assumed to have a single unique presentation.
For most other blocks, however, you might have several different ways in which you want the block to appear. In other words, the mark-up (view) might be entirely different for two different instances of the SAME block type. Thus, by keeping the bock's implementation logic separate from the view, you can change the look of the block without altering any of its logic. This is done by choosing "Custom Template" from the popup menu for the block when the page is in edit mode.
-Steve
+1 to this -- the "custom templates" feature is the most prominent and useful example of the benefits of MVC in Concrete5.
Hmm...well...that's on example of a benefit to MVC that is a good one.
I may well have picked the worst possible example of the benefit (or lackof) to the MVC approach in the form block I have been playing with (it's not the default Form block or the External Form Block but rather a custom created one that was available off the forum but one that still does things more or less the C5 way...though with code that was much easier to follow).
Custom templates may indeed be one of the strongest pluses to the MVC approach.
I'll have to wait and see if MVC grows on me as I continue using C5.
Carlos
I may well have picked the worst possible example of the benefit (or lackof) to the MVC approach in the form block I have been playing with (it's not the default Form block or the External Form Block but rather a custom created one that was available off the forum but one that still does things more or less the C5 way...though with code that was much easier to follow).
Custom templates may indeed be one of the strongest pluses to the MVC approach.
I'll have to wait and see if MVC grows on me as I continue using C5.
Carlos
I realize this is an old thread and I'll try to be brief.
As others have mentioned, whether MVC makes your life easier or harder depends on what kind of applications you have to write. If you are writing a contact form, then the simplest, easiest approach is top down, one single file holding all the logic, or maybe two files one for the data/logic and the other for the markup. However, the web has changed from simple things like contact forms to increasingly complex applications. MVC and other design patterns has come out of developers experiencing the pain of the overly simple approach. Its a pattern that even predates the web and has been used successfully over and over on many applications. What its trying to accomplish is something called "Separation of concerns" that makes understanding and writing complex applications much easier.
If you have not built a lot of complex applications (not saying you haven't, i dont know) you will be unlikely to understand the benefits of MVC. Also, Concrete may not be the best place to learn MVC, as it does not always follow it well. Some things in Concrete are just complicated because you are dealing with a 3rd party CMS and have nothing to do with MVC. You should look at the other frameworks you mentioned and also Ruby on Rails or ASP.NET MVC. Judge the pattern in its own right, not how its fits into concrete. You should also learn about design patterns in general and concepts like single responsibility principle and separation of concerns which MVC is based on. These are also tried and true concepts in programming that once you have down, help tremendously. One thing that always bothers me in this industry is that people learn all this technology but do not go back and learn the concepts, methodologies and principles that have already been discovered and helps make us good programmers. MVC is one of those.
My opinion, for what its worth, after writing both simple and complex web applications
for 13 years, is that MVC is a definite plus. Like everything, there is a learning curve, but once you have it down, it cleans up your code, makes things more readable and separates everything nicely, making development and maintenance (especially) much, much easier. Yes, its annoying to have to make at least 3 files just to build something absurdly simple like a contact form, but i'd rather have the consistency of everything in MVC than have some parts of an app in MVC and some parts just spaghetti coded.
Anyway, i hope this helps you and other PHP and Concrete5 developers.
As others have mentioned, whether MVC makes your life easier or harder depends on what kind of applications you have to write. If you are writing a contact form, then the simplest, easiest approach is top down, one single file holding all the logic, or maybe two files one for the data/logic and the other for the markup. However, the web has changed from simple things like contact forms to increasingly complex applications. MVC and other design patterns has come out of developers experiencing the pain of the overly simple approach. Its a pattern that even predates the web and has been used successfully over and over on many applications. What its trying to accomplish is something called "Separation of concerns" that makes understanding and writing complex applications much easier.
If you have not built a lot of complex applications (not saying you haven't, i dont know) you will be unlikely to understand the benefits of MVC. Also, Concrete may not be the best place to learn MVC, as it does not always follow it well. Some things in Concrete are just complicated because you are dealing with a 3rd party CMS and have nothing to do with MVC. You should look at the other frameworks you mentioned and also Ruby on Rails or ASP.NET MVC. Judge the pattern in its own right, not how its fits into concrete. You should also learn about design patterns in general and concepts like single responsibility principle and separation of concerns which MVC is based on. These are also tried and true concepts in programming that once you have down, help tremendously. One thing that always bothers me in this industry is that people learn all this technology but do not go back and learn the concepts, methodologies and principles that have already been discovered and helps make us good programmers. MVC is one of those.
My opinion, for what its worth, after writing both simple and complex web applications
for 13 years, is that MVC is a definite plus. Like everything, there is a learning curve, but once you have it down, it cleans up your code, makes things more readable and separates everything nicely, making development and maintenance (especially) much, much easier. Yes, its annoying to have to make at least 3 files just to build something absurdly simple like a contact form, but i'd rather have the consistency of everything in MVC than have some parts of an app in MVC and some parts just spaghetti coded.
Anyway, i hope this helps you and other PHP and Concrete5 developers.
Would i call it easier? Not necessarily. It depends on what you do with your code, how you like to code, and what kind of code you write. The truly simple stuff that is true single use case there may not be a reason to use MVC there. A concrete5 core php file included in a tools folder or one that is generally interacted with and returning json is as close to standard php as i think you get.
Taking your logic and segregating/abstracting it away into base classes is one of the main reasons that most developers will like MVC...done right you don't ever have to write the same function twice, or duplicate the same code...you can use the same controller(after all...it is a php class) to handle tools requests, ajax requests, the standard action based method calls..things like that.
So while it is indeed a bit more work to code MVC...you will start to see the benefits the more you work with it, I'd suggest reading:
ProPHP Patterns Frameworks Testing and More by Kevin McArthur and the rest of the apress pro line..you'll kind of see the benefits.
I don't really want to talk about any of the stuff I have been working on because it doesn't really do anyone any good, but I feel like a lot of people get MVC and framework envy is in regard to how Rails or cakephp handles their MVC with cakePHP's bake commands and rails scaffolding...
There really isn't anything stopping you from doing this in concrete5..concrete5 with its Model (by virtue of filesystem folder name, and not class inheritance requirement) leaves it with open for you to implement a more closely tied activerecord implementation like adodb in concrete5 or you can even use redbean(that's kinda cool) and others.
Trying to mix that in with a procedural one liner script would be a huge mess and you'll be glad you are doing mvc there :)
TLDR It's more typing, but its the future so i'd suggest getting used to it.