I'm fairly certain my professor will ask me why I chose to use MVC for my web application.
Truth be told, I'm new to MVC. I read about it, I'm building a blog application using it, I think it's very logical to approach a problem this way.
But why? O_O I draw a blank. How is better suited than say, building an N-tier application?
Well, basically: separation of concerns on the usage level, not the physical level.
Quoting PoEAA on MVC
MVC splits user interface interaction into three distinct roles.
With MVC , you are separating presentation (V, C) from the domain logic (M) and you also separate UI behavior (C) from UI display (V). This is much more maintainable than intermingling all three concerns into one and it also fosters reuse and testing. It allows you to better tackle complexity.
This is nothing that just applies to Web Applications. It is suitable for any applications with domain logic and a UI. With that said, I wouldn't say MVC is the best-suited pattern for a web app though. If all you wanna do is put, say, a Contact Form on the web, then an all-in-one-page script would be sufficient. If you only got a bunch of static pages, MVC is overkill too. So like with any patterns, it depends on the problem you want to solve.
As for the n-tier, the "classic" MVC did not foresee it's use on the Web. With the presentation of the UI happening in the browser and the controller on a remote server, MVC on the web is always also a Multi-Tier architecture, hence the difference between usecase and physical in the beginning. MVC is just not concerned where it happens.
Also see:
What is MVC and what are the advantages of it?
MVC VS N-Tiers
Related
Does MVC really means you have to separate => View aka design (html css) => controler (php code), model (mysql code into classes etc.)???
Are there not alternatives? Wondering because I would really like to avoid separating php code and mysqli as right now it's sooo easy to work on it (got used to it).
Yes, you definitely want to separate HTML and CSS from business logic.
Most frameworks use an ORM or something similar to abstract building queries but still give you the option to write plain SQL. I would recommend to use an ORM like doctrine2 for example over plain SQL. If you use any SQL directly the model would most likely the right place to put it into.
MVC exists for a reason, separation of concerns. This makes sure that your application becomes easy to maintain because every part of it should be easy to replace and not depend on each other to much. You want to avoid strong coupling. MVC is a pattern that helps you with that.
And like tttpapi said, there other ways to do it, but honestly, I personally think that specially Wordpress for example is a horrible clutter. I don't like Drupal or Joomla as well. The code base feels like working with 10 year old clutter compared to a modern well written application following the MVC pattern.
This is a little about discipline es well, I've seen totally messed up applications as well because people did not pay attention to separation of concerns and didn't follow the MVC pattern.
Does MVC really means you have to separate => View aka design (html
css) => controler (php code), model (mysql code into classes etc.)???
No.
MVC is about separation pf concerns. It separates presentation layer from model layer. And within presentation layer - it separates handling of input (controllers) from handling of output (views).
The model in MVC is not a databases abstraction or collection of queries. Instead it is a layer that contains several groups of classes. The major groups are domain objects, data mappers and services. The model in MVC is all these things taken together.
Longer explanation: here
Note: do not confuse MVC's model with domain model, which is the accumulated knowledge and vocabulary for specifica application. The part of domain model, that can be encompassed in code, is implemented using domain objects.
View is not html and css. Views in MVC are classes that contain the UI logic for the application. THey acquire data from model layer and then, based in this information, choose which templates to use for producing a response.
Longer explanation: here
Controllers are not some mystical "php code". They are part of application that takes user input, and based on that alter the state of model layer and (in rare cases) state of current view.
Are there not alternatives? Wondering because I would really like to
avoid separating php code and mysqli as right now it's sooo easy to
work on it (got used to it).
The point is NOT separating SQL from PHP.
The separation of concerns principle simply means that each part of your application should be dealing with one specific aspect.
And, if you try to implement MVC architecture, it will NOT mean that you separate sql from php, but that you separate business logic from persistence logic. Both of those would be written in PHP. But the trick is - MySQL is not the only form of storage. Data can also be stored in session, in cache, in noSQL, in files, in SOAP, etc. If you have separated business logic from persistence logic, then you can add caching to your existing application without rewriting the whole thing.
Also ...
There are more architectures then just MVC and Big Ball of Mud (which was advertised by people who talked about Drupal and Joomla).
You have MVP, MVVM, n-Tier, DCI, EDA and many others. And all these will be adhering to SoC principle .. but the result that they come up with will be different.
P.S.: If you actually want to learn about MVC, I would recommend for you to start going through materials from this list. It will start by introduction to simple concepts and gradually build up to ideas that you have to grasp to actually start working with MVC.
It is always up to you.
You always can find way how to use MVC as nonMVC. (example is Joomla here you can use just view with all code in it)
Or you can use systems that are not MVC bases such as Drupal.
But the MVC is here for some reasons.
To directly answer your question, yes MVC means exactly that.
However MVC is just a design pattern, and not a holy writ.
There are many variations available to you. I myself initially thought MVC to be restrictive and confusing, but in fact it was the particular MVC based framework i choose that had these failings.
There are many lightweight, flexable frameworks available. Take a look at https://github.com/bcosca/fatfree as a nice example, in particular the database section. You wont think mysqli is simple in comparison
I've been learning Zend and its MVC application structure for my new job, and found that working with it just bothered me for reasons I couldn't quite put my finger on. Then during the course of my studies I came across articles such as MVC: No Silver Bullet and this podcast on the topic of MVC and web applications. The guy in the podcast made a very good case against MVC as a web application architecture and nailed a lot of what was bugging me on the head.
However, the question remains, if MVC isn't really a good fit for web applications, what is?
It all depends on your coding style. Here's the secret: It is impossible to write classical MVC in PHP.
Any framework which claims you can is lying to you. The reality is that frameworks themselves cannot even implement MVC -- your code can. But that's not as good a marketing pitch, I guess.
To implement a classical MVC it would require for you to have persistent Models to begin with. Additionally, Model should inform View about the changes (observer pattern), which too is impossible in your vanilla PHP page (you can do something close to classical MVC, if you use sockets, but that's impractical for real website).
In web development you actually have 4 other MVC-inspired solutions:
Model2 MVC: View is requesting data from the Model and then deciding how to render it and which templates to use. Controller is responsible for changing the state of both View and Model.
MVVM: Controller is swapped out for a ViewModel, which is responsible for the translation between View's expectations and Models's logic. View requests data from controller, which translates the request so that Model can understand it.
Most often you would use this when you have no control over either views or the model layer.
MVP (what php frameworks call "MVC"): Presenter requests information from Model, collects it, modifies it, and passes it to the passive View.
To explore this pattern, I would recommend for you begin with this publication. It will explain it in detail.
HMVC (or PAC): differs from Model2 with ability of a controller to execute sub-controllers. Each with own triad of M, V and C. You gain modularity and maintainability, but pay with some hit in performance.
Anyway. The bottom line is: you haven't really used MVC.
But if you are sick of all the MVC-like structures, you can look into:
event driven architectures
n-Tier architecture
And then there is always the DCI paradigm, but it has some issues when applied to PHP (you cannot cast to a class in PHP .. not without ugly hacks).
From my experience, the benefits you get from an MVC architecture far outweighs its costs and apparent overhead when developing for the web.
For someone starting out with a complex MVC framework, it can be a little daunting to make the extra effort of separating the three layers, and getting a good feel as to what belongs where (some things are obvious, others can be quite border-line and tend to be good topics of discussion). I think this cost pays for itself in the long run, especially if you're expecting your application to grow or to be maintained over a reasonable period of time.
I've had situations where the cost of creating a new API to allow other clients to connect to an existing web application was extremely low, due to good separation of the layers: the business logic wasn't at all connected to the presentation, so it was cake.
In the current MVC framework eco-system I believe your mileage may vary greatly, since the principles are common, but there are alot of differences between, for instance, Zend, Django, RoR and SpringMVC.
If there are truly other good alternatives to this paradigm out there... I'm quite interested in the answers!
Sorry for the slight wall of text!
I think it would depend on what you're trying to do, personally. Magenta uses MVC pretty successfully, and it makes it fairly easy to add new functionality or modify existing.
Of course if you're trying to make something fairly simple, going with an MVC architecture could be overkill.
It's all preference. I have worked with old structures like XTemplates and Smarty and have now moved on to Codeigniter and Kohona. I like them very much and they work very well for everything I do on the web. For phone applications I can set up controllers for the functions that are needed to do it's data pulls as well. Working both in the Linux world and Windows World, for building ASP.NET Web Sites I don't see other way of building websites beside using MVC. Web Applications Projects in Visual Studio are still used but I prefer not to anymore. MVC Projects via Visual Studio is so easy to use and set up. You can right click on your controller methods and create views automatically. In every structure there is a good and bad but it's up to the developer to use whatever meets their needs.
I have asked a similar question before and got an convincing answer as well?
What is difference of developing a website in MVC and 3-Tier or N-tier architecture?
Due to the conclusion of this question I started developing projects in N-tier Architecture.
Just about an hour ago, I asked another question, about what is the best design pattern to create interface? There the most voted answer is suggesting me to use MVC architecture.
What is the best design pattern to design the interface of an WebPage?
Now I am confused, First post suggested me that both are similar, just a difference that in N-tier, the tier are physically and logically separated and one layer has access to the one above and below it but not all the layers.
I think ASP.net used 3 Tier architecture while developing applications or Web applications. Where as frameworks like Zend, Symphony they use MVC.
I just want to stick to a pattern that is best suitable for WebProject Development? May be this is a very silly confusion? But if someone could clear this confusion, that would be very greatful?
They aren't mutually exclusive. The Model-View-Controller pattern is really a user interface design pattern, and it concerns logical rather than physical tiers.
I most often hear "n-tier architecture" used to describe the actual physical separation of an application's layers. For example, a system in which the user interface runs in one process, exchanges data with an application layer (perhaps via messaging or web services) that executes in another process (perhaps on another server), which in turn accesses a data layer that runs in yet another process (typically a database server).
This description can be particularly confusing because 'application logic' can mean multiple things: in an n-tier system it usually means business logic - as opposed to user interface logic (like which widgets are enabled when the user selects a particular checkbox).
For example, in an n-tier system, your presentation layer might call a web service method that accepts an item ID. The web service runs on a different server, where it performs complicated calculations and returns a price.
In a simpler architecture, your application might calculate the item's price in the same process as the user interface - though the pricing logic may be separated into its own logical layer (perhaps within library or executable).
I can't think of any current MVC frameworks that care whether their layers run in separate physical processes or not.
I just want to stick to a pattern that
is best suitable for WebProject
Development? May be this is a very
silly confusion? But if someone could
clear this confusion, that would be
very greatful?
I think your confusion lies in two areas:
1) The assumption that there's one solution for every problem.
The requirement of your project will dictate which solution is best.
2) The definition of MVC when applied to the web is different than when it originally applied to desktop applications.
Some folks say that if the view doesn't talk to the model, then it can't be MVC. Well, most of the web MVC implementations don't have the view talk to the model, yet it's still called MVC.
Since you are a self-described amateur, you should embrace this one axiom early on: the programming world is confusing to everyone all the time.
You may want to review the Microsoft Application Architecture Guide. It has a good overview of the available Microsoft technologies from an Architecture standpoint. Chapters that might be of interest to you:
Chp 21 Designing Web Applications
Appendix B: Presentation Technology Matrix
Appendix C: Data Access Technology Matrix
As for what is best? You have to answer that yourself. Make some sample projects using MVC, WebForms, etc.
Web-based MVC is much different than the traditional desktop MVC. The Model simply has no way to update the View, because the web is (for the most part) stateless.
Even if you used AJAX to poll the server every couple seconds to check for Model updates, that still wouldn't be "true" MVC because it's not the Model notifying the View, it's the controller constantly "querying" the Models.
The lesson learned is that it really doesn't matter what you label your architecture. There are just so many variants of MVC/3 tier that usually people just lump them under the "MVC" blanket. And all of these are suitable for web development. I just can't think of any practical way to have the Model actually notify the View through server-side programming (at least not in PHP). If you need this kind of behavior, you should be writing a desktop application. Just write what is natural for you and don't get caught up in terminology debates. Look at what some of the well known frameworks like CodeIgniter, Kohana, Symfony, CakePHP, and Zend do and pick and choose which features or design patterns you like.
Why not use both?
At the moment I'm busy developing a project using the MVP pattern and in an N-tier architecture.
I'm using the MVP pattern in the user interface project, ie. the website. All the data which needs to be shown and used in the website is passed from a webservice. This webservice is connected to a business layer (BLL), which is connected to the data access layer (DAL). The DAL is connected to the database using the Entity Framework.
So in this project I'm using them both. Using MVP instead of MVC though.
This way the interface project (website) doesn't has to do hard stuff, only pass through some data which is received from the webservice. Took me a while to set up, but it works quite wonderfull.
Also, there is no real answer to which pattern or architecture is the best. It all depends on what you want and need. If you want to be scalable, an n-tier architecture is a good solution. If you want to be able to test your UI quite easily, an MVC pattern is good also. There's a ton of other patterns and architectures which would suffice as well, as long as you know how to use them.
There is no which is better. MVC and n-tier are not either or things. One is object/API design, one is system architecture. The question to distinguish between the two has been asked and answered here:
MVC Vs n-tier architecture
I have a large website that I have time to convert to a nice custom-framework that I can build to my needs. I want to build my own, and not use something like Smarty because I'd like to...
know how all the guts of it work
cut any and all bloat
learn it, just for kicks
But, after building it in different ways, several times...I keep feeling that for the amount of "convenience" it offers, the code becomes increasingly unflexible, attempting to keep track of files becomes triple as hard (especially if you are the lone developer on the project), and there isn't even any real awesome documentation out there.
At this point, I really need convincing...how is this going to change my life, again?
This has been answered already, but to put a finer point on it, I think the single attribute that encompasses when to/not MVC is scalability:
MVC allows clear seperation of duties (ie, front-end vs. database coders).
MVC is a pattern that enforces uniform coding habits.
Maintainability is increased as it's easier for a new project member (who understands MVC) to grok the codebase.
If you are the sole owner of the code and don't forsee other people joining anytime soon, then you should not need it.
It can be difficult (sometimes impossible) To convert an existing project to some new pattern/framework. It also depends on how you are implementing an MVC framework.
You say that keeping track of files is hard. While you may end up with more files, they shouldn't be hard to keep track of if you have a good organization and naming system, i.e. keeping models, views, and controllers in 3 separate folders, or have some kind of naming convention that tells you what is what
I also don't understand why you see the code as more 'unflexible'. Having code properly seperated into Models, Views, and Controllers is that it is more modular, and it can prevent code duplication.
The most important thing about having this seperation of concerns is Maintenance. One of the biggest benefits of an MVC framework is that is easier to pick out what code is misbehaving and fix it. The seperation of concers = a seperation of problems & bugs.
It is probably most convenient in the sense that it is an accepted pattern, and other people drifting in and out of your project will understand it. The big thing about Design Patterns, the book, was not that the patterns were new, but that they all suddenly had accepted names.
If you are and will be the sole updater, it may be no big deal.
The greatest thing about MVC is that it's really just a concept. How you implement it is up to you as long as you follow the standard of separating duties.
I've written a few different MVC code bases based on what needs to happen in the project. One code base has a service layer to further separate "business logic" from the controller and views. Another one separated CLI controllers from web controllers.
This is just how I look at and use MVC. I suggest finding some credible documents or blog posts online about MVC.
What I love about MVC is that when you come to hand it over to another developer, whether that be a new employee or for long-term support, anyone with a knowledge of MVC can figure out what's going on very quickly.
That's not to say it's the best way of looking at things, but it is a way that most people understand.
After doing MVC or HMVC there is no way that I could possibly go back to spaghetti coding. It will take a bit of time to switch over a large site depending on how extensive the backend is, but depending on how much maintenance you are doing, it may be worth it.
Can i ask what makes you want to do a custom framework? I mean, I don't doubt anything, it is just that technology advancements keep growing-- I don't highly recommend drupal or cake.. I would recommend something like Kohanaphp.com where it is very lightweight and has a great database connector called ORM (object relational mapping) which is a great usage of MVC. The best part is that you won't have to fully maintain your framework as it is opensource and has an active community. Although, being a programmer myself, I do understand how we grow attached to our code and want it our way :D But this saves time by already offering tools for request handers, xss filtering, routing and bootstrap configurations, etc.
Just a thought :D
I want to know which php architecture strategies developers use in complex php applications . So far , i know the mvc structure which consists of models, views and controller (and controller plugins which handle with common tasks such as user access controller ). I know some good php frameworks which makes some common stuffs easier .But the problem starts when i thing about huge and complex php applications . because in these applications there are lots of stuff to do or lots of think to check, so i can not decide which code should be where .
Think about magento application , this is very huge application . when i review the source code of application , i can not understand the design strategy . i know there are some perfect design strategies which can handle very big php applications easily , because they can not build such a huge application with a very weak design strategy .the design strategy should support more than you want , so you can improve your code and application easily
To sum up , i want to how can i create bigger applications . Now the design strategies i use in my applications limits me , so i can not create more complex applications . i want to know which the design strategy can handle complex applications.
i know this is very abstract question , but this is because now my php background coming from amateur hobby not from academic . i want to do more , but i am in somewhere where i can not go one step more , because i can not find more complex info about coding . whatever ,to sum up , i want to know about design strategies for complex php applications such as magento .
Maybe the design strategies which i know (mvc , frameworks ci cake ...)can handle more complex applications than i think ..
if there are some mistakes in my questions please feel free to correct them , sorry for my inadequate english ..
I believe that part of your problem may lie in the fact that creating enterprise applications is a problem in any language, and the design patterns that can implemented are actually language agnostic.
I would strongly recommend that you familiarize yourself with Patterns of Enterprise Application Architecture by Martin Fowler. This is the seminal work for any other books that you may later pick up that cover the same concepts in a language specific format, and if you want to truly understand what is required to create robust, scalable applications on the web then you'll need to familiarize yourself with this book.
A very common and popular design strategy with web applications right now is the Model-View-Controller paradigm. This has to do completely with separation of concerns in your application so that you aren't mingling database access code with html output.
For a pretty good treatment of the topic I would suggest that you look here (Zend Framework specific but it covers the general topic well) and here for a discussion about Models specifically. Or if you want to look at a more generalized PHP MVC tutorial, Rasmus Lerdorf has one.
In addition to this (and again you can learn this from PofEAA by Martin Fowler) you will need to learn about Object-Relational-Mapping what the strengths and weaknesses are of the various design patterns.
Unfortunately there are many good ways to do things depending on your needs, but for every good way there are about a zillion horribly wrong ways to them.
Which frameworks have you examined? Examine symfony, Zend Framework, and CakePHP if you haven't already. And by examine, I mean actually write medium-sized applications using these frameworks. Simply reading code is often not enough to get a grasp of how it works. You often have to actually use it and try to modify it.
You may also want to check out the book PHP 5 Objects Patterns and Practice for some ideas of design strategies that you may apply to your application. You may also learn quite a bit by studying frameworks written in other languages. The designers of many of the PHP frameworks were heavily inspired by Ruby on Rails, for example.
It is indeed very abstract question and "very complex" is not very specific. When I hear people talking about "complex" applications I associate it with
a) Someone is using a complex architecture for a simple Problem. E.g. by using every design pattern and framework that sounded cool.
b) Someone tried to squish tons of entirely different usecase into a historically grown application, creating and using proprietary and undocumented interfaces and couple everything as tightly together as possible. Unfortunately CAN build huge applications with a bad design strategy and that is what makes them complex.
c) Legacy systems and Legacy System integration (ok see b)
Magento may be a big application, but the underlying Framework is still the Zend Framework, mainly its MVC part. So reading the Zend_Framework documentation will help you a lot to understand Magentos architecture as well (I won't recommend it the other way around by trying to dig into the Zend Framework through the Magento source).
I would recommend to actually start building a bigger application with one of the MVC frameworks yourself, because that is the best way to learn the architecture and its benefits and where the limits are.
If you haven't already, you should look into Object-Oriented Programming. There is a really great tutorial about that here. I think this is perhaps the most important thing that big web apps do that isn't necessarily intuitive to the amateur (myself included). The trick in MVC frameworks like Code Igniter is to build a series of classes (or objects) as either models or libraries.
Well, even if your question just all about PHP... If you handle your static content like images with PHP it will result poor performance no matter using you MVC or not. You should use front end like nginx for such things.
look at http://highscalability.com/ real stories from real life!
Also note NoSQL.
Catalog of Patterns of Enterprise Application Architecture
.
I tried to understand your problem and found that magento architecture is very powerfull but complicated. I got a solution by Zendfox, It is a web application framework, suitable for small to huge application development. It has very cute application architecture that can be manage very easily. It also has module developer to create custom modules for zendfox within few minutes wizard based tool.
So take a look at: http://www.zendfox.com