Hi , In MVC pattern we usally refer M - Model - DataBase V - View - JSP /HTML C- Controller -Servlets why can't we mention the Servlets as View and JSP as controller. Because both the servlet and JSP both are same.
V- View -Servlet C - Controller - JSP why can't mention like that?
MVC is just a name for a design. You could certainly use servlets, JSPs and Plain Old Java Objects in other ways, but it probably wouldn't be MVC then. There are variations like document view (edited to correct that) that combine view and controller.
Some rules boiled down from MVC:
No presentation code in the model. My project has built services that are used by web pages, fat clients and other system clients. Interestingly when the web people tried to use exactly the API methods that the fat client used, the results sucked, so the model is not perfectly reusable.
No business logic in the view. Some express this as no Java in the JSP - only HTML and tags. Of course tags are expressive enough to do some business logic, but we're supposed to know better.
Servlet is a natural controller because it gets control from the web request (also known as receiving user gestures) and it's straight Java so it can do the use case level logic. JSP is a natural view generator because you can eliminate all Java logic from it.
Clearer or confusinger? [ May 15, 2004: Message edited by: Stan James ]
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
Anna, You could do that, but it would be awkward. JSPs are suited to presentation (view.) The view could be in a servlet, but it would be harder to read/code. Servlets are better suited to logic, so they serve the role of controller better. It's better to keep logic out of a JSP.
I'm not sure if you're asking a question about semantics or concept. Are you saying why do we use those words to refer to those entities? Or are you saying why don't want apply the concept of "view" to servlets and "controller" to JSPs, letting those entities actually exchange code?
If you're talking about semantics, I think if you understand the problem that MVC solves, the reason we use that terminology will become clear. If you're talking about changing the model, then perhaps you don't understand the problem domain that MVC addresses.
The fact is, MVC only addresses that particular problem domain. The problem MVC solves is: what if I want to represent an object in several different ways interchangably? So, let's say you write an application that keeps polling statistics. A bunch of people take surveys, answering questions about what flavor of ice cream they like, and then you write an app that displays the information. You could use a pie chart (20% chocolate, 30% strawberry, and 50% vanilla), or a histogram, or any number of views into that data. You might even decide that you want to be able to add views later to the codebase that you haven't even thought of yet. In that case, it makes sense to use MVC because with MVC, you write the model, you write a controller, and you write a view interface. The controller coordinates between the model (which holds the percentages associated with each flavor) and the view to make sure the view is always informed of whatever changes have happened to the data in the model. (You would probably want to implement this using an event model, where the model and view both register listeners with the controller and the controller registers listeners with each of the other two as well, that way they can all keep tabs on each other.)
Once you have that done, then you can start implementing the view interface with Histogram, PieChart, and whatever other classes you can think of. Adding a new kind of view is as simple as adding a single class that implements the view interface.
There are a lot of different approaches to splitting up responsibilities into separate components, just like MVC, only except separating view code from model code from controller code, you might want to separate out different aspects. So, MVC is really just one kind of Component Object Model, and you might be thinking of splitting things up a little differently because you want to solve a different problem. That's fine, but you'll just be creating a new COM which is appropriate for solving some different problem.
Another example of a COM is EJBs. If you read up on those, you might start to see how different COMs can solve different problems and get a better feel for the whole thing.
Originally posted by sever oon: The controller coordinates between the model (which holds the percentages associated with each flavor) and the view to make sure the view is always informed of whatever changes have happened to the data in the model. (You would probably want to implement this using an event model, where the model and view both register listeners with the controller and the controller registers listeners with each of the other two as well, that way they can all keep tabs on each other.)
This is a common misconception about MVC, but in the vanilla form of the pattern, the Controller *does not* sit between the Model and the View. That would be more like Model View Presenter; in MVC, the View typically directly observes the Model.
The Controller is responsible for interpreting user input (typically in the form of http requests in web applications). It translates the input into commands for the Model and/or the View. The intent is to be able to change the form of user input without affecting the code that handles business logic or presentation.
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
Joined: Feb 08, 2004
That's interesting, Ilja, and I won't presume to challenge that your statement about MVC is true. I rarely find that MVC is an applicable COM to most problems in its straight form, though.
For instance, in a desktop application, the user is working directly with the components that make up the presentation. The view components themselves get the clicks and characters and other user inputs. If the view components are to remain "stupid", then they should forward the raw data on to the controller, let the controller interpret the input and transform it into commands for both of the other two, the model and the view, and issue those commands.
So in this situation, the part of the system communicating user inputs (without interpreting them) happens to be the view, hence the controller does kind of sit between the other two components.
I will admit that I've always been a bit flummoxed by MVC when it comes to managing the dependencies between the three components. The controller expects to be directing around the view and model components, so I suppose it makes sense that it use those APIs directly when it needs to (as opposed to the approach I mentioned above, where the view and model would register listeners with the controller). Should the view invert that relationship by calling the controller's API directly when it has user input to pass on? Then you have a circular dependency, so that doesn't ring true to me.
Should the controller register a listener with the view, then, to keep the dependency relationship one way? This approach seems more appropriate because it allows the view to define the event listener interface it expects to work with for the controller to implement. But by having the view now play this role as the supplier of user input to the controller, another problem creeps in...say that there can be more than one path for user input to arrive. Now does this second means of sending information to the controller redefine the same listener interface and have the controller implement it separately? That doesn't seem to make sense...so the event listener interface seems to vary with the controller--the type of user input the controller can handle--and should not change if the view happens to change or if there are multiple input sources to the controller. So do we place the listener interface back with the controller?
We're back to square one. Now the view, in playing its role of relaying user info, must depend upon a controller component once again (even though it's not the controller object, the listener interface is now, in a sense, part of the controller).
I've given this thought from time to time and I've never been able to come up with a solid answer that seems to address all of the problems at once. It seems like MVC is really a binary component object model made up of a model component and a view-controller component. The view is oftentimes inexorably intertwined with the controller anyway; two different views may define a different set of user inputs that the controller needs to be able to handle. Consider a pie chart and a histogram view of the same model, and the user selects the y-axis of the histogram (to rescale the view, or something). How is this view component supposed to relay this information, which exists purely as a feature of that particular view, to the controller? Contrast this with something view-independent, such as selecting one of the bars in the histogram (the controller could correctly also highlight the appropriate pie wedge, so in this there is no conflict).
Maybe I just have a complete misunderstanding of MVC, but I've never been able to adequately answer these questions to my own satisfaction.
Joined: Jan 29, 2003
I've seen view & controller implemented so that they know each other intimately and you get that circular dependency. Circles within a package are not ideal, but pretty much impossible to eliminate completely, so maybe we could all live with that.
You can remove that dependency by having some other object that we haven't seen yet introduce the players to each other as interfaces.
View, meet this controller interface implementer who will listen for user gesture events.
Controller, meet this view interface implementer who will open and close windows at your request.
Controller meet this model interface implementor who will accept data change messages.
Model, meet this view interface implementer who will listen for changes in data.
Now everybody depends on interfaces. We can get very clever with who owns the interfaces. For example, if the controller package owns controller and view, then view package depends on controller package but not vice versa. Or we can stick all the interfaces in a very stable, abstract package all by themselves so model, view and controller packages have NO dependencies on each other. Cool in its own way.
Joined: Feb 08, 2004
I've always thought that if MVC is to be an important component object model, then it should follow the basic rules of good design, meaning no circular dependencies. The problem with making "one little exception" for this case when dealing with MVC is that it's used everywhere. That "one little exception" is built into your project in a major way if you decide to go with MVC. Consequently, whatever bad things that come along with circular dependency are now part of your project in a big way.
No, this can't be right...and interfaces can't be the answer, though they technically break the dependencies, they don't provide the satisfaction I'm looking for. For a very simple example, we shouldn't have to resort to a three-interface, three-object solution. We need to get an expert in here to weigh in on this. I know I'm missing something. MVC can't possibly be the most-used COM of all time and have this sort of basic shortfalling. Can it?
Joined: Jan 29, 2003
Couple different points ... interfaces are key to breaking and directing dependencies. Let's say Model (the component, not the class) is supposed to send notification of data changes to View. With concrete classes, Model would have to know the View class in order to hold a reference to View. That would be bad. If Model owns the interface DataChangeListener and view implements the interface, then view depends on model. Probably good. (I can make up exceptions, but they'd be very strange.)
And the old definition that "view interprets user gestures". I don't know how literally to take that. If Controller registers a listener for View.buttonX clicked, then Controller is rigid and only works with views that actually have buttonX. Maybe that's ok and you develop View and Controller as a set. Note that controller can still work with multiple views, but all the views must have a buttonX.
Or maybe that's a bit too close to the user gesture. I've done some programs where Controller registers for View.userAskedToDoSomething. View maps buttonX or menuY or timerZ to userAskedToDoSomething and passes that event to Controller. So View is doing a little interpretation of user gestures on its own. I felt it gave a very nice separation of responsibilities between View and Controller when complete.
This would support View using any kind of widget it wants to set a value or trigger an action.