a blog on Zend Framework - Part 2: The MVC Application Architecture
Looking good texts to document experiences with Zend Framework, I find a very good series of articles for practicing, the original texts are in English and unfortunately for us, the blog that contained (http: / / blog.astrumfutura.com) no longer exists, so I'm doing a sweep of the Internet to collect them again, As I'm trying to ensure compatibility with the latest version of ZF. Part 2: That if it was in English, then translated, or at least I'll do possible, any correction will be well received. :)
Saturday, August 30, 2008
Catholic Patron Saint Of Happiness
If you are waiting for the source code appears (I would say, is in the wrong place lol), this will only happen in the next installment.
Previously: Part 1 Introduction and planning
After talking to multiple users on how to start with a framework, I found that many do not have a sophisticated understanding of what we call the "cornerstone" of a framework web applications today, I say: The design pattern Model-View-Controller, so we'll know more about him, and first started looking into PHP. As antecedents, consider the traditional and still popular approach to writing an application in PHP. It usually takes an approach called "The driver of the page." Each HTML of your application can have its own dedicated PHP file - often this ends in many HTML pages for PHP file, but only if those pages are similar enough (eg, forms and form processing are typical) such that the relationship is formed out of the need to reuse the code in the same file. Often, these pages share a collection of functions, classes and constants, for xample, every page could neceistar Smarty, or a connection to a database or even perhaps a model for collecting data about users, ACL, etc. The problem is that in this scenario is very difficult (but not impossible) gestioanr growth and change. Each change and each new feature requires new code. When you finish putting the new code, this becomes a huge concern. You may need to add several changes to various pieces of application logic, but then finds that the logic is scattered across multiple PHP files, may find that your connection reusable database now has SQL statements 12 files, now it is necessary to reference to a new field in the table. Can you imagine the spread of small changes to multiple files, finally exploding exponentially until they end up in a situation where the cost of change far exceeds the benefits. This is the point at which a project is simply stagnated despite the enthusiasm of its developers, and to be clear, I've fallen into that trap before ;-). what's done is done, I discovered the pleasure of Object Oriented Programming and reform my practice.
The Model-View-Controller
The Model-View-Controller (or MVC as it is frequently abbreviated) is a general solution to the question of how to separate responsibilities in an application and in certain highly structured way. The name of the pattern mentioned the three divisions: Model, View and Controller. Although MVCpodría apparently one of those esoteric concepts in programming, is now a very simple concept. You pick up some pieces of functionality, determine its purpose and assigned to one of the three separations, and then to a specific class. Once everything is divided properly, complete with small pieces that are reusable, centralized, accessible and fit within the building blocks won an Abstract API - now working with abstracted APIs ago incremental changes extremely simple (If done correctly of course ;-)). With all carefully organized into objects with specific responsibilities for the cost of change is significantly reduced (which is actually the whole point we want to change to be cheap and easy.) Obviously I'm not covering the entire field of object-oriented programming. Esespero But the message is clear enough. Also object-oriented nature of the Zend framework is largely why it contains so many elements. Not only have the Zend_Controller - We Zend_Controller_Action, Zend_Controller_Router, Zend_ControllerFront, etc. each specific role or responsibility is covered by their own kind. This will undoubtedly translate into an abundance of classes centered at the point where it can be difficult to see how all the pieces work - but honestly, all you need is the API abstracts and may ignore the rest unless you really want to customize something. To be clear, the MVC is common as dirt, is widely used in Zend Framework, Solar, Symphony, Ruby on Rails, Merb, Django, Spring and a number of Frameworks. This is a concept not to forget the time for a web application framework in almost any language.
Model
The model is responsible to maintain state between HTTP requests and a PHP web application. Any data that must be preserved between HTTP requests is for the segment model of your application. It also incorporates the rules and restrictions governing the data, is called the "business logic." For example if you write the business logic for a model of order in an application for inventory management, internal controls dictate that the company could purchase orders are subject to a single cash purchase limit of € 500. Purchases of more than € 500 would be considered illegal actions by the computer model (unless perhaps authorized by someone with a higher authority). Therefore, the models are the logical place for access to data, but ta, biñen could act as a centralized location to examine, verify and make the final manipulation of the data, before they are stored, and even after be recovered.
Sight
The view is responsible for generating the user interface for an application. In PHP, it is often strictly defined as where they are placed around the presentational HTML. While this is true, it is also where is total create a system of dynamic generation of HTML, RSS, XML, JSON or even nothing but all that will be sent to the client browser or application. Normally, the view is organized into templates, but can also be simply returned by the "echo" php or manipulated by the driver before departure. It is essential to remember that Vista is not just a file format, but also includes all the PHP code tags or analysis used to organize, filter, decorate and manipulate the format based on data extracted from one or more models (or as often, what model is passed from view by the driver). On a side note, this blog is not going to use Smarty. Smarty has respected the history of PHP, but has shortcomings Garver once you start thinking like a puzzle view of dozens of reusable parts drawn together into a single overall design. Indeed, this method of administration of the View is closely related to OOP as a concept which uses PHP as template language, it becomes almost inevitable. That not without a cost (all the designers know PHP?) But is a manageable cost.
driver
Drivers are deceptively simple in comparison with others. The main function of the controller is to control and delegate. In a typical PHP request to an MVC architecture, the controller takes what is entered by the user, monitors the information filtering, validating and processing the input, given the model, and then delegates the output to be generated by the view (optional what happens to one or more models required for processing the current template). The controller also has a unique difference from other forms of architecture in PHP, since it only requires a single point of entry into the application - cas inevitably index.php. Controller vs Model
A quick view of MVC would not be complete without a brief that referred to at least one common difference in MVC applications. I borrow a term, this is the idea of \u200b\u200ba model and a controller Gordo Flaco. Gordo A model is a model that has as much business logic and data manipulation as can fit in it. The result is a large body of reusable logic and accessible from any controller. This, in theory, result in a driver Flaco - when all logic is contained within a suitable model behind some APIs, the Controller of average size should be reduced controller Less code, less ordinary code hidden in what a driver does . opposite is a model Thin and Fat Controller - The business logic is in the driver which obviously increases its size, and second means that the code is not reusable (a Mensa decided to reuse the controller from another controller - which is rarely a good idea efficiently wise). Together, these are the three segments of an application architecture that implements a Model-View-Controller. It is a widely recognized solution for applications wen and is evident in most of the current generation of Frameworks for many programming languages.
In the Zend Framework, three separations these peripheral components are represented by Zend_Db, Zend_View and Zend_Controller. Will be hearing a lot about these three and the classes that make up the chapters to come. Together, these form the backbone of the Zend Framework MVC architecture and relies heavily on best practices.
The Model-View-Controller was originally used to promote the "separation of interests" in the desktop applications with GUI. By separating each interest in a separate layer of the application. resulting in a decrease of the coupling which in turn made it easier the design, writing, testing and maintenance of applications. Although applications with graphical user interface (GUI) have strayed from the past MVC , has demostradado be highly effective when implemented in Web applications.
In the Framework, this adds a lot of predictable structures from each segment of the MVC for any supported this request apart within their own group of files. The controller is represented by Zend_Controller_Front and Zend_Controller_Action subclasses, the subclasses of Zend_Db_Table model and the view for template files. Phtml and View Helpers. The Zend Framework manages the organization of each of them in the picture, leaving you free to focus only on those groups without worrying about all the code that is to combinarsen.
In a sense it's like building a house foundations, walls and interior wiring and plumbing are already in place, and all that remains to be done is the interior and roof. It may take some time to learn how to decorate and roof sections that are already ready, but once you've learned how to do it, then the houses will be completed much faster.
In Conclusion
As I said, this is a very brief understanding of the MVC. It is not exhaustive, so feel free to run a few searches on Google and read about it. For Web application developers, reading about MVC is never a waste. There is a huge body of existing thoughts that cover topics ranging from testing for MVC MVC until styles work best for different situations. : investigating an example of "Hello world" example is not as simple as possible, since it illustrates some cleaning standards to keep this simple example is more orderly and malleable as possible. Si. :-) have actual PHP code
---------------------------------------- - END
Previously: Part 1 Introduction and planning
After talking to multiple users on how to start with a framework, I found that many do not have a sophisticated understanding of what we call the "cornerstone" of a framework web applications today, I say: The design pattern Model-View-Controller, so we'll know more about him, and first started looking into PHP. As antecedents, consider the traditional and still popular approach to writing an application in PHP. It usually takes an approach called "The driver of the page." Each HTML of your application can have its own dedicated PHP file - often this ends in many HTML pages for PHP file, but only if those pages are similar enough (eg, forms and form processing are typical) such that the relationship is formed out of the need to reuse the code in the same file. Often, these pages share a collection of functions, classes and constants, for xample, every page could neceistar Smarty, or a connection to a database or even perhaps a model for collecting data about users, ACL, etc. The problem is that in this scenario is very difficult (but not impossible) gestioanr growth and change. Each change and each new feature requires new code. When you finish putting the new code, this becomes a huge concern. You may need to add several changes to various pieces of application logic, but then finds that the logic is scattered across multiple PHP files, may find that your connection reusable database now has SQL statements 12 files, now it is necessary to reference to a new field in the table. Can you imagine the spread of small changes to multiple files, finally exploding exponentially until they end up in a situation where the cost of change far exceeds the benefits. This is the point at which a project is simply stagnated despite the enthusiasm of its developers, and to be clear, I've fallen into that trap before ;-). what's done is done, I discovered the pleasure of Object Oriented Programming and reform my practice.
The Model-View-Controller
The Model-View-Controller (or MVC as it is frequently abbreviated) is a general solution to the question of how to separate responsibilities in an application and in certain highly structured way. The name of the pattern mentioned the three divisions: Model, View and Controller. Although MVCpodría apparently one of those esoteric concepts in programming, is now a very simple concept. You pick up some pieces of functionality, determine its purpose and assigned to one of the three separations, and then to a specific class. Once everything is divided properly, complete with small pieces that are reusable, centralized, accessible and fit within the building blocks won an Abstract API - now working with abstracted APIs ago incremental changes extremely simple (If done correctly of course ;-)). With all carefully organized into objects with specific responsibilities for the cost of change is significantly reduced (which is actually the whole point we want to change to be cheap and easy.) Obviously I'm not covering the entire field of object-oriented programming. Esespero But the message is clear enough. Also object-oriented nature of the Zend framework is largely why it contains so many elements. Not only have the Zend_Controller - We Zend_Controller_Action, Zend_Controller_Router, Zend_ControllerFront, etc. each specific role or responsibility is covered by their own kind. This will undoubtedly translate into an abundance of classes centered at the point where it can be difficult to see how all the pieces work - but honestly, all you need is the API abstracts and may ignore the rest unless you really want to customize something. To be clear, the MVC is common as dirt, is widely used in Zend Framework, Solar, Symphony, Ruby on Rails, Merb, Django, Spring and a number of Frameworks. This is a concept not to forget the time for a web application framework in almost any language.
Model
The model is responsible to maintain state between HTTP requests and a PHP web application. Any data that must be preserved between HTTP requests is for the segment model of your application. It also incorporates the rules and restrictions governing the data, is called the "business logic." For example if you write the business logic for a model of order in an application for inventory management, internal controls dictate that the company could purchase orders are subject to a single cash purchase limit of € 500. Purchases of more than € 500 would be considered illegal actions by the computer model (unless perhaps authorized by someone with a higher authority). Therefore, the models are the logical place for access to data, but ta, biñen could act as a centralized location to examine, verify and make the final manipulation of the data, before they are stored, and even after be recovered.
Sight
The view is responsible for generating the user interface for an application. In PHP, it is often strictly defined as where they are placed around the presentational HTML. While this is true, it is also where is total create a system of dynamic generation of HTML, RSS, XML, JSON or even nothing but all that will be sent to the client browser or application. Normally, the view is organized into templates, but can also be simply returned by the "echo" php or manipulated by the driver before departure. It is essential to remember that Vista is not just a file format, but also includes all the PHP code tags or analysis used to organize, filter, decorate and manipulate the format based on data extracted from one or more models (or as often, what model is passed from view by the driver). On a side note, this blog is not going to use Smarty. Smarty has respected the history of PHP, but has shortcomings Garver once you start thinking like a puzzle view of dozens of reusable parts drawn together into a single overall design. Indeed, this method of administration of the View is closely related to OOP as a concept which uses PHP as template language, it becomes almost inevitable. That not without a cost (all the designers know PHP?) But is a manageable cost.
driver
Drivers are deceptively simple in comparison with others. The main function of the controller is to control and delegate. In a typical PHP request to an MVC architecture, the controller takes what is entered by the user, monitors the information filtering, validating and processing the input, given the model, and then delegates the output to be generated by the view (optional what happens to one or more models required for processing the current template). The controller also has a unique difference from other forms of architecture in PHP, since it only requires a single point of entry into the application - cas inevitably index.php. Controller vs Model
A quick view of MVC would not be complete without a brief that referred to at least one common difference in MVC applications. I borrow a term, this is the idea of \u200b\u200ba model and a controller Gordo Flaco. Gordo A model is a model that has as much business logic and data manipulation as can fit in it. The result is a large body of reusable logic and accessible from any controller. This, in theory, result in a driver Flaco - when all logic is contained within a suitable model behind some APIs, the Controller of average size should be reduced controller Less code, less ordinary code hidden in what a driver does . opposite is a model Thin and Fat Controller - The business logic is in the driver which obviously increases its size, and second means that the code is not reusable (a Mensa decided to reuse the controller from another controller - which is rarely a good idea efficiently wise). Together, these are the three segments of an application architecture that implements a Model-View-Controller. It is a widely recognized solution for applications wen and is evident in most of the current generation of Frameworks for many programming languages.
In the Zend Framework, three separations these peripheral components are represented by Zend_Db, Zend_View and Zend_Controller. Will be hearing a lot about these three and the classes that make up the chapters to come. Together, these form the backbone of the Zend Framework MVC architecture and relies heavily on best practices.
The Model-View-Controller was originally used to promote the "separation of interests" in the desktop applications with GUI. By separating each interest in a separate layer of the application. resulting in a decrease of the coupling which in turn made it easier the design, writing, testing and maintenance of applications. Although applications with graphical user interface (GUI) have strayed from the past MVC , has demostradado be highly effective when implemented in Web applications.
In the Framework, this adds a lot of predictable structures from each segment of the MVC for any supported this request apart within their own group of files. The controller is represented by Zend_Controller_Front and Zend_Controller_Action subclasses, the subclasses of Zend_Db_Table model and the view for template files. Phtml and View Helpers. The Zend Framework manages the organization of each of them in the picture, leaving you free to focus only on those groups without worrying about all the code that is to combinarsen.
In a sense it's like building a house foundations, walls and interior wiring and plumbing are already in place, and all that remains to be done is the interior and roof. It may take some time to learn how to decorate and roof sections that are already ready, but once you've learned how to do it, then the houses will be completed much faster.
In Conclusion
As I said, this is a very brief understanding of the MVC. It is not exhaustive, so feel free to run a few searches on Google and read about it. For Web application developers, reading about MVC is never a waste. There is a huge body of existing thoughts that cover topics ranging from testing for MVC MVC until styles work best for different situations. : investigating an example of "Hello world" example is not as simple as possible, since it illustrates some cleaning standards to keep this simple example is more orderly and malleable as possible. Si. :-) have actual PHP code
---------------------------------------- - END
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment