MWLUG 2015 - An Introduction to MVC

Editor's Notes

• #11: Software Design Patterns are about reusable designs, interaction of objects and high quality solution to a given requirement, task or recurring problem. So Design Patterns are documented, tried and tested solutions or recurring problems in a give context. They are reliable and they speed up software development process.
• #12: Let’s 1st talk about software design patterns. Software design patterns can be defined as recurring solutions to common problems in software design. You might be wondering how does your application work without design patterns if this’s so important. The main point to understand is that if your application doesn’t contain any errors it will work like a charm. But working application does not mean that your application’s codebase is up to the industry standard. Just writing code is not gonna help you but writing the code right way will help you. GOF A.K.A. Gang Of Four(Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides) are considered to be the gurus of software design patterns. They introduced 23 design patterns which fall into three types. Creational design patterns, Structural design patterns and behavioural design patterns. http://en.wikipedia.org/wiki/Software_design_pattern
• #13: http://en.wikipedia.org/wiki/Software_design_pattern
• #14: 1970-s: "A Pattern Language" , by C. Alexander, et al. , 1977 (available at amazon.com) 1980-s: Hillside Group - Beck, Ward, Coplien, Booch, Kerth, Johnson, etc. 1995 - the famous book - "Design Patterns: Elements of Reusable Object Oriented Software", 1995, by the so-called Gang of Four (GoF), that is Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides - see their photo:
• #16: https://www.lri.fr/~mbl/ENS/FONDIHM/2013/papers/Krasner-JOOP88.pdf The MVC pattern has subsequently evolved,[13] giving rise to variants such as HMVC, MVA, MVP, MVVM, and others that adapted MVC to different contexts
• #22: An easy way to understand MVC: the model is the data, the view is the window on the screen, and the controller is the glue between the two A model is an object representing data or even activity, e.g. a database table or even some plant-floor production-machine process. A view is some form of visualization of the state of the model. A controller offers facilities to change the state of the model Controller The Controller in the MVC comes at the last, but is the most used part of the MVC pattern. It is used to work with the HTTP requests, coming from the clients; from the browsers or from any other application that can generate an HttpRequest (not to be confused with the .NET’s HttpRequest object; but a simple HTTP Request). Each request, when comes, is handled by the Controller and then Controller, according to the request makes decisions to load the data, create the response and then sends the data back to the client. It should also be noted here, that your Controller acts as a bridge between your Model and the View. Because they, as themself, cannot perform any action. Controller triggers their events and makes them do something, like return data from Model, or to render the HTML document from the View etc. All of the resources and errors are also handled by the Controller. Making it the heart of the pattern, because the response is also sent back from a controller. You can think of an example of a Controller to be the entire Business-logic-layer. The code that is used to run the application’s back-end processing, like creating accounts, managing solutions etc, would make up the Controller section of this pattern. View Next comes the part of the View, this is the actual web page that is being displayed to the user. It contains the HTML codes that are to be sent back to the data as a response to his request. Correct, Controller sends this response back to the client, View – its self – doesn’t send this response to client whereas Controllers takes this data, and sends back to the client. View, can also be created dynamically. As already said, all of the requests are handled by Controller, so any parameter (including QueryStrings) can also be handled by Controllers. Using these parameters, we can generate dynamic Views. So dynamic content in our view, change their layouts or show some other error messages if the data sent is not of our own choice. View, generally depends on the Model that is being used to create the View and these dynamic data objects are capture from the Model (Model is discussed in the next section). Point to be noted here is that while section-in-action is View, still Controller is playing a vital role for passing the values and for retrieving the data to be sent to client. Model As the name suggests, it is a model of some object. The object in this case is our application’s data. It can be of any type, like extracted from a database; no matter which one, SQL Server, MySQL or MS Access etc, or it can be a simple data that comes from a Reporting, or from a Spreadsheet etc. Model is never shown to the user (actually, the client) because he is supposed to see the data and the results we want him to see, that is why, it is a good approach to keep a great abstraction layer between Model and the user (the client). Model doesn’t only store the data, it – at the same time – keeps the View and the Controller updated or any change being made to it. Models are designed, just like Controllers and Views are designed, just so that there is no ambiguity between three of them and it is easy for them to communicate to make the web application fluent. Everytime a change is made, View is update by the Controller, because Controller is informed about the change (this informing event is also raised by Controller; as I already said, Controller handles the events). To store anything in the Model, the user has not been provided with any form that is directly connected to the Model, instead a form is generated in the View by the Controller for the user to fill in. Once the form is filled, the form values are then passed to the model for storing purposes. All kinds of data validations (most special type of which are SQL Injections) can be checked at the Controller level rather than loosing (important) data.
• #33: Every XPages has a corresponding Java class Hero -> HeroBean, Overview -> OverviewBean
• #34: When the user submits the URL, in the BEFORE phase event the Appcontroller gets the page name from the url. It first splits the URL to get the last part -> Overview.xsp, then again, it splits the result to just get the name -> Overview From the VIEW package, it gets the class OverviewBean, creates a new instance and stores the object in the viewScope.
• #35: There is no classic data binding. The repeat control accesses the viewScope. The viewScope is manipulated by the AppController. „page“ contains the bean object for the page.
• #39: The Data Access Object Pattern, also known as the DAO pattern, abstracts the retrieval of data from a data resource such as a database. The concept is to "separate a data resource's client interface from its data access mechanism." The problem with accessing data directly is that the source of the data can change. Consider, for example, that your application is deployed in an environment that accesses an Oracle database. Then it is subsequently deployed to an environment that uses Microsoft SQL Server. If your application uses stored procedures and database-specific code (such as generating a number sequence), how do you handle that in your application? You have two options: Rewrite your application to use SQL Server instead of Oracle (or add conditional code to handle the differences), or Create a layer inbetween your application logic and the data access The Data Access Object pattern does the latter. The benefits of the DAO pattern are obvious, but the implementation is a little tricky. To properly implement the DAO pattern you need to generate the following components: DAO Interface DAO Factory DAO Implementation classes Deployment Descriptor Entry The DAO pattern, in and of itself, does not necessarily require a factory, but in practice you will see the two patterns coupled. The reason is that some mechanism needs to be created to obtain the appropriate implementation class and using a factory is the cleanest implementation http://www.informit.com/guides/content.aspx?g=java&seqNum=137 http://www.tutorialspoint.com/design_pattern/data_access_object_pattern.htm