0

I've learned that you should set up the controller-class in a MVC-OOD as a use case, from top to bottom in only one method that run the MVC-classes.

Is it OK to use different methods in one controller to get more control and better overview?

Let's say you wanna run a controller that will display a login form (getting the html etc from the View). And the same controller will also display a log-out button IF the user is NOT logged in. This could be done with a single method in the controller, but using two methods seems better. One method to call if you want the login form, and one to call if you want to log-out button. (just an example)

So, what does the pros say. Should each controller contain one "use case" method only, or could it be several?

user1121487
  • 2,662
  • 8
  • 42
  • 63
  • the view can simply check the state of the user's model and decide to show or not the log out button.. it's not OO but maybe you are looking for Role based access control more generally –  Oct 18 '12 at 18:37

2 Answers2

1

TL;DR -- you have misunderstood the MVC design pattern and are doing it wrong.

Controllers are not responsible for rendering the interface, nor for presentation logic. Controllers do not display anything. Instead, each controller's method deals with different user's request. It extracts the data from said request and passes it to model layer and the associated view.

Decisions about what and how to display are in purview of views. Views contain the presentation logic in MVC pattern. In the context of web applications, views create the response. They can compose a from from multiple templates or just send a single HTTP header.

Controllers can signal the associated view by passing some specific values of the request to that view, but most of the decisions in the view are based on information that the view requested from different services in the model layer.

A Controller's methods are based on what type of requests a user can send. For example in a authentication form it might be: GET /login and/or POST /login.

Leigh
  • 12,859
  • 3
  • 39
  • 60
tereško
  • 58,060
  • 25
  • 98
  • 150
  • I know what it does. The controller displays the form, getting it FROM the view etc etc, This was NOT the question! – user1121487 Oct 18 '12 at 15:55
  • 1
    @user1121487 The "answer" was in the last paragraph. And the point of rest of the post was that you **do not** understand what controllers are supposed to do. I don't know where you learned about MVC design pattern, but it's all **WRONG**. – tereško Oct 18 '12 at 16:17
  • You can do MVC in more than one way. The way I learned it, was from my programming teacher at the university. The controller collect data from the view, from view to model, and back and returning it to the place where the controller is instanced. Instead of using a lot of if-statements in the controller, I thought about using more than one method. And that was the question. – user1121487 Oct 18 '12 at 17:08
  • 1
    Are you aware that there is no view to collect from, when you apply MVC pattern to web? Controller does not collect anything from. View is not required for controller to work. It only needs input from user. Controller managed the request and changes the state of model **layer**, the view generate the response by combining the information it received from controller with data which it requests from model layer. **CONTROLLERS ARE NOT RESPONSIBLE FOR SENDING DATA FROM MODEL LAYER TO VIEWS NOR FOR CREATING THE RESPONSE!!** – tereško Oct 18 '12 at 17:17
  • GET, POST, COOKIE datas must be collected from the view. SESSION, database, file etc collected from the model. This is the way my teachers say it's done. If you use for example GET in the controller or model, you fail. The model and view can communicate as well but the controller is designed as a use case: username = view.GetUsername(); model.CheckUsername(username); – user1121487 Oct 18 '12 at 17:23
  • The values in `GET`, `POST` and `COOKIE` are not part of view. The MVC triad receives them from browser as a request. View does not exist at that point. The routing mechanism turns it in a `Request` object. Both view and controller is instantiated based on data that was extracted in routing process. Controller does not read any data from view. You are being taught be someone who does not understand web or how MVC pattern applies to it. And model is NOT AN OBJECT OR CLASS. It is a layer. – tereško Oct 18 '12 at 17:35
  • @tereško agreed, most web architectures designed in mvc will have the request routed to a controller, model is updated, and view get these infos back to the user. it's unilateral most of the time. but if you think of a long communication between the user and the server, there are more edges in the graph –  Oct 18 '12 at 17:49
  • If you wanna access a POST, GET values HTML etc, you do that by calling a function in the view that returns that value TO the controller. I'm pretty sure my university teachers know what they're doing. And I don't think you have knowledge of all ways of doing MVC. And it's nothing getting frantic about over the internet. MVC is not religion, it's for separating logic and presentation. – user1121487 Oct 18 '12 at 17:53
  • @user1121487 the mvc architecture on the server, has a http request input, a http response output, in most cases. that's mostly how the client interacts, it doesn't "returns that value TO the controller" , (except long-lived connections). teresko is right in its answer –  Oct 18 '12 at 18:05
  • @user1121487 please read [**this**](http://www.itu.dk/courses/VOP/E2005/VOP2005E/8_mvc_krasner_and_pope.pdf) and [**this**](http://martinfowler.com/eaaDev/uiArchs.html). Your teacher should have already pointed you to these two articles already. – tereško Oct 18 '12 at 18:07
0

Its important to remember two things with MVC, firstly, its an Object-Oriented Architecture, and secondly, It should be used for separating concerns.

Separation of Concerns is related to Abstraction, It is to aid us in understanding the section of code at hand. The Model and View are both collections/domains of related objects. Each object is fully complete and relevant to its domain.

You will find objects with types such as Buttons, Images, Text Inputs etc inside your View, and you will find business related objects (User, Account, Profile etc) within your Model.

The collection of objects inside your Model don't tend to do much, They require logic to wire the objects together. (Or simply delegate simple single object requests to the correct object)

The Controller provides the interface into your Model, and contains the business logic related to the Model and the interactions between the Model objects. You will have a single Controller for your Model, and the Controller will have multiple methods which will align with your use-cases.

Michael Brown
  • 498
  • 4
  • 13