leon_nerd wrote:What I understood was this is a concept that is used to keep the designing and programming aspects independent of each other. Am I right?
Not based on standard meanings for 'designing' and 'programming', so you really need to get some understanding about what MVC means first. However I think you may be gleaning one of the key goals of MVC and all other such architectural patterns. If by 'programming' you mean the information and business rules of the application; and by 'designing' you mean the presentation of that information -- then yes, you are on the right track.
I think one of the points of confusion when reading about MVC is that, because it was a response to traditional N-Tier architectures, MVC is often called "triangular" (to differentiate it from 3-Tier). In fact, if compare MVC and 3-Tier you find that what MVC really does is follow the 3-Tier where the Data Tier == DataSource Layer and Logic Tier == Model Layer. But MVC divides the Presentation Tier into two parts -- the Controller that deals with the Request and program flow, and the View that deals with presentation logic and the Response.
Where 3-Tier is an "I" shaped stack with Presentation Tier sitting on the Logic Tier sitting on the Data Tire -- MVC is a "T" shaped stack with the Controller and View at the top in the Presentation Layer sitting on the Model Layer sitting on the DataSource Layer. It is really important to understand that the Model is in one layer and the View/Controller are in a different, higher layer. This is essential to understanding MVC. The separation between View and Controller is less important (but more often argued

). In fact if you combine the View and Controller you are really just doing 3-Tier -- which is a proven architecture.
There key to both of these architectures is the separations. They are the essence of Modular Programming. The ultimate Best Practice is to separate the Models/BusinessLogic from the Presentation code of the system. That gives you many proven benefits in stability, maintainability, extendability, portability, reuse, etc. because it isolates the informational foundations of the application from the whims of displaying it. I do want to note that MVC is actually
two separations (not three). The first, and most important, separation is between the Model and Presentation layers. The second separation is inside the Presentation layer between the View and Controller.
You also need to separate MVC from MVC frameworks. The latter can support MVC and ususally do it by implementing a Front/Action Controller system that is a good fit with MVC. The Action Controller then loads Model and View object. This system encourages/enforces the two separations.