CS6320 – MVC L. Grewe

THE ISSUE: Separating Implementation from Interface The business logic stays the same regardless of what the presentation is The business logic stays the same regardless of what the presentation is The business logic does not depend on the presentation medium, and different presentation media may be used for the same business logic The business logic does not depend on the presentation medium, and different presentation media may be used for the same business logic Separating the business logic from the presentation results in more modular and reusable code Separating the business logic from the presentation results in more modular and reusable code

The MVC Framework MVC = Model – View – Controller MVC = Model – View – Controller Model = Data (state of entity) Model = Data (state of entity) View = Interface (visualization of entity) View = Interface (visualization of entity) Controller = Business Logic - communication between the interface and the data layer Controller = Business Logic - communication between the interface and the data layer The controller may be a separate class, or just specific methods in the business logic class that are used for the communicationThe controller may be a separate class, or just specific methods in the business logic class that are used for the communication

MVC Pattern

The Model Object Knows about the data needed to be manipulated Knows about the data needed to be manipulated Knows about the business logic, including operations that can be performed on the data Knows about the business logic, including operations that can be performed on the data Data should be accessed and manipulated using methods, independent of the GUI Data should be accessed and manipulated using methods, independent of the GUI e.g., A clock – the model only keeps track of the time, with an internal representation, and does not have anything to do with how it is displayed e.g., A clock – the model only keeps track of the time, with an internal representation, and does not have anything to do with how it is displayed Will allow external controls to modify state Will allow external controls to modify state

The View Object Should refer to the model to update its display Should refer to the model to update its display Query the model using accessor methods to retrieve data from the model Query the model using accessor methods to retrieve data from the model Same model can have different views: Same model can have different views: A clock can have an analog viewA clock can have an analog view A clock can have a digital viewA clock can have a digital view A clock can be used as a timer/stopwatchA clock can be used as a timer/stopwatch Note that the model for all of the above is the sameNote that the model for all of the above is the same Different views would have no bearing on the intrinsic behavior of the model Different views would have no bearing on the intrinsic behavior of the model

The Controller Object Knows about physical means by which users manipulate data in the model Knows about physical means by which users manipulate data in the model Responds to events from the GUI and translates them to method calls for the model Responds to events from the GUI and translates them to method calls for the model Usually sits between the user interface and the model – and calls model methods based on view operations Usually sits between the user interface and the model – and calls model methods based on view operations e.g., setting the time of a clock by typing in the current time would cause the controller to trap the action event and calling, say, the “setTime” method of clocke.g., setting the time of a clock by typing in the current time would cause the controller to trap the action event and calling, say, the “setTime” method of clock Often controller will not need interaction of the model (e.g., for sorting a view) Often controller will not need interaction of the model (e.g., for sorting a view)

What does this mean? When you design business logic classes, you should not use any explicit I/O (except for test code – maybe in the main() method) When you design business logic classes, you should not use any explicit I/O (except for test code – maybe in the main() method) All interaction between business logic classes and the outside world through public methods All interaction between business logic classes and the outside world through public methods When you use interface classes (application classes, servlets, JSP) you should not use any explicit business logic When you use interface classes (application classes, servlets, JSP) you should not use any explicit business logic Only code in interfaces classes should be class instantiation and method calls Only code in interfaces classes should be class instantiation and method calls