All...I'm getting hung up a bit on the distinctions of the M layer and the C layer. I work for a power company, so let me use the following example. Some GUI has a drop down box and a button on it. Clearly, the View. Now, the functionality that determines what list of power plants ought to appear as options in that drop down box and puts them there is part of the _____________ layer? My initial answer to this question would be the Model layer makes the determination and the Control layer puts them there. Is this correct? Furthermore, a particular power plant is selected and the button is clicked. The end result of the button click is something like this: Power plant _______ has produced ________ megawatts year-to-date. //Simple values retrieved from a table or view somewhere. Power plant _______ is projected to produce ________ megawatts for the entire year. /* A calculated figure based off of some algorithm that uses the previous YTD value and the prior 5 years' values. */ I am having a hard time grasping the clear-cut segregation of the Model and the Control. I would appreciate it very much if anyone could fit some or all of the situation I have described into the proper layer. Thanks [ February 11, 2004: Message edited by: Bryan Noll ] [ February 11, 2004: Message edited by: Bryan Noll ] [ February 11, 2004: Message edited by: Bryan Noll ]
Sorry Rian, but I have to disagree. The Controller is like a traffic cop. it acts as a go-between for the presentation (View) and the business logic (Model). It directs the flow of requests from the View to the Model and back. The Controller usually passes any requests coming from the View to an appropriate Business Delegate (Model) which in turn is responsible for the actual business logic processing. Your description "Model" actually fits the description of a Transfer Object which is a means of transporting data from one layer to another. Implementing the scenario would probably be something like this: GUI (View) --> request for list of power plants --> Controller receives request and determines that the PowerPlant (Model) should handle it --> Controller hooks GUI up with PowerPlant, tells PowerPlant what the request was (at this point Controller is done) --> PowerPlant asks PowerPlantDAO (DB/boundary) to access persisted data --> PowerPlantDAO retrieves data from storage, populates PowerPlant --> PowerPlant indicates it is has processed the request --> GUI shows PowerPlant's current state. Other implementations are also possible where the Controller plays a more active role and stays in the middle of it all throughout the process, acting as the channel of communication (instead of just being the catalyst) between the View and the Model.
Your description "Model" actually fits the description of a Transfer Object which is a means of transporting data from one layer to another.
Thanks for the response. Its clearing up a bit. Maybe I didn't communicate it well in my original post, but I've never thought of the Model as a transferer type of object. In my mind, its more of a state/processing type of object. The state being the data and the processing being anything that needs to be done to that data. Would these thoughts indicate that I'm thinking of it correctly, or am I still way off in right field? [ February 12, 2004: Message edited by: Bryan Noll ]
The model can be as active as it needs to be. It represents business domain data and functionality that is independent of the view. A good model could be used by a web view, a fat client view, an API view, etc. Just to run down the workings again:
I threw in human-view actions there. Humans are a bit too squishy for this kind of diagram, but I hope it makes sense. I'm nuts about dependencies. Controller and View seem to know about each other. Controller opens windows so it has to know views. Views send events to controllers. How do you avoid circular package dependencies? One way is for the view package to own an interface that controller must implement to get event notification. The controller creates the view and adds itself as a listener for events. Now the view package doesn't have any dependency on a particular controller package. Model must not know about controller or view. I'd like to be able to use it with new controllers and views without recompiling. So the model package owns the interface that the view package implements to be notified of model changes. The controller creates the view and adds the view to the model as a listener for model change events. The bit about the client asking the model for the latest data is optional. The model can "push" all the changed data along with the notification so the view does not have to reference the model. Hope all that helped. There are zillions of ways to interpret MVC in fat client, client-server, web, etc, so no answer is completely "right" all the time.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Junilu Lacar: Sorry Rian, but I have to disagree. The Controller is like a traffic cop. it acts as a go-between for the presentation (View) and the business logic (Model). It directs the flow of requests from the View to the Model and back.
This description seems to be in conflict with your example, where the model directly communicates to the view that its state has changed. And I actually think that the example is correct - the controller is responsible for handling input, but doesn't need to know about any output.
Other implementations are also possible where the Controller plays a more active role and stays in the middle of it all throughout the process, acting as the channel of communication (instead of just being the catalyst) between the View and the Model.
Yes - that's probably more like the Model View Presenter pattern, then?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Model View Controller.... The View is very clear, the Controller is the one that tells where to go, fo example: which screen is next, or which action should be performed. the model performs these actions, I guess an understandable description for me is that the model represents your business. you would perform all business rules and validations here.