Live data from Hacker News

MVC is dead, it's time to MOVE on

cirw.in

151–160 of 233 posts

Re: MVC is dead, it's time to MOVE on

#151
post #117
post #23

This sure looks like MVC, but they call the Controller "operations". The MVC abstraction has an issue with web applications, since the request-response cycle doesn't provide feedback as directly as the hardware-monitor-software cycle that the pattern was originally designed around. However, if the problem is that you are putting too much "logic" into your controllers, you should probably find a better place for it. I…

It's very similar you're correct, particularly when you add in the Manager/Service layer (something that I hadn't spent enough time investigating). The main advantage of Operations over controllers is that they're fully composable. You can take the operation that logs a user in (which displays the login screen, and awaits the user typing a username and password) and use it as a sub-part of any other operation. In a p…

Right, but in an MVC web-app, the Controller defines the "end-point". Meaning it should end there. The composition of different pieces of functionality should be happening in the area of the business logic.

I understand the motivation, and have come across several situations where I wanted "controllers calling controllers", but ultimately, you're repurposing a piece of the architecture to do something it shouldn't be doing. A controller handles the input into the system, it shouldn't be defining a workflow.

> In a purer MVC world you get something similar to this by making a function that instantiates the login controller with its associated view; that's pretty good, but there's no obvious place to put that function.

That just sounds backwards to me. Are talking about creating dynamic endpoints? That sounds like a much bigger headache than composing stuff in a service layer.

MVC can be a little ambiguous, and with web-frameworks it can be hard to see that each piece is actually a subsystem. The Model isn't just your model class, its the model class, the DB and the ORM library you are running. Similarly, the View is the entire response / template rendering subsystem. The part that is addressed in the framework is mostly the "controller" subsystem, which is a way of organizing code so that the actual "controllers" can do the primary work of sanitizing input, delegating function calls and returning the output to the View system.

Again, MVC is just a pattern that doesn't fit perfectly in the web request/response cycle, which then necessitates a pattern to handle the leakage (in my case I'm talking about the service/manager pattern). However, I just don't see your suggestions that MVC is "dead", or how this system is radically different.

It seems like it is just semantics.

Re: MVC is dead, it's time to MOVE on

#153

Earlier quoted context omitted.

So it's only a view when you write all your code to push bits to the monitor yourself. Outputting using libraries that convert formats like html (-> browser -> os/driver -> screen) aren't views. Got it.

Let me give you an example. In your model, you have represented the salary of an employee as an integer. In a web application, the salary can be presented to the user through numerous different views - as a number on the screen (plain HTML), as a slider (jQuery UI slider), as a bar in a bar chart (using some charting library). The tools you use to build the view are not relevant.

Ohhhh, I see now. So some data formats that render to screen through external software are views, like html, json, generated javscript or xml if they go through jQueryUI or charting libraries, but if it goes through other external software like RSS readers, or non html, json, or javscript formats, before making it to the screen, it is no longer a view. Thanks for the clarification!

Re: MVC is dead, it's time to MOVE on

#154
post #150

Earlier quoted context omitted.

In an MVC, the views are used both for output of the model and to map input back to the controllers. Without the input, its not part of the MVC pattern.

Bullshit. Please show me your Rails-or-similar app that's doing INPUT parsing in the view (embedded JS doesn't count)

When you click a link on a web page, it gets routed to a controller action. Thats done because the link was generated with the url: example.com/controller/action. Its not about parsing input, its about routing.

Re: MVC is dead, it's time to MOVE on

#155

Are you talking about pure mvc's like sproutcore? faux mvc's like backbone? model2 patterns like rails and most other server side architectures? I think what you mean is 'Model2 is dead...'. MVC is great for any environment where the observer pattern can be implemented (eg web front-end). The biggest problems I've seen in model 2 architectures is weak models. The side effect of this is everything gets stuffed in the…

In practical terms, those observers would have to live in the controller, or there would be coupling between the model and views.

The observer is supposed to be baked into the framework itself. Theoretically, setting a value on your model will update the view without you having to write any code.

Re: MVC is dead, it's time to MOVE on

#156

Earlier quoted context omitted.

> in fact, the wikipedia article on MVC is slightly off on the subject, assuming one accepts the original Xerox description as a source. People complaining about factual inaccuracies on Wikipedia annoy me. It's Wikipedia. The entire point and purpose of it is to fix what you know is wrong. For once, I'd like to see, "I just touched up the Wikipedia article on this subject to explain it a bit more accurately."

>"I just touched up the Wikipedia article on this subject to explain it a bit more accurately." "But then all my changes were reverted by an overprotective editor; I brought the issues up on the talk page, but my comments were brusquely dismissed."

Your changes would still be in the edit log, and someone more savvy in Wikipedia politics would have the opportunity to get your changes cemented. Said person might be another HN reader who is less knowledgeable about the subject matter.

If you don't make any changes, he has nothing to work with except some random whining.

(And yes, that's how it works in the real world, too.)

Re: MVC is dead, it's time to MOVE on

#157
post #141

Is there something structured like hacker news that focuses on articles with content like this? I find this a lot more interesting than threads about entrepreneurship but I don't know where to go to read about things like this.

Good question. Architecture doesn't get debated much on the Internet (probably because it's easier to bash PHP), but here's to hoping there is a place where people argue about this more.

Re: MVC is dead, it's time to MOVE on

#158
post #92
post #56

The best practices I've seen for MVC apps isn't to put all the logic in the controllers. What you do is to create a "services" or "managers" layer that is called on by the controllers. A userService, for example, might have a function user = userService.login(name, password) It's also nice to abstract this service layer with some clean interfaces so that you can replace the underlying implementation, for example to m…

I prefer to put anything ORM-related inside the model. This way, I free views and controllers from the specifics of the platform and, as long as I keep the model API the same, I can move from one platform to another easily. If userService.login method knows how to check a User's password, it's probably inextricably tied to the model and, therefore, part of it. Even if it's on a different module, it cannot be reused w…

I also prefer this approach. The excellent book 'Domain Driven Design - Tackling Complexity in the Heart of Software' by Eric Evans has helped me a lot. I'd write something like:

  service = AuthService::getInstance();
    }
    // reflection calls a Module + Action attribute to {module}Controller
    public function login(Request $request) {
      if ($request->getRequestMethod() === WebRequest::POST) {

        if ($this->service->login($request->getAttribute('username'), $request->getAttribute('response')) {
          die('{ "success" : true }');
        } else {
          die('{ "success" : false }');
        }
      }
    }
  }
  class AuthService { // Application Service -> it just defines a clear API, not a Domain Driven Design service
    public function __construct(Session $session) {
      $this->session = $session;
    }

    public function login($username, $response) {
      try {
        $user = User::getRepository()->getByUsername($username);

        return $user->isValidChallengeResponse($this->session->getAttribute('challenge', 'auth'), $response);

      } catch (UserDoesNotExistException $e) { }
      return false;
    }
  }
  class User {
    protected static $repository;
    public static function setRepository(IUserRepository $repository) {
      self::$repository = $repository;
    }
    public function getRepository() {
      return self::$repository;
    }

    // yeah yeah, it is arguably if this belongs as a Domain method of the user…
    public function isValidChallengeResponse($challenge, $response) {
      // and yes, this is very weak challenge response…
      return md5($challenge . $this->getPassword()) === $response;
    }
  }
  ?>
If anyone can tell me what's wrong with this type of MVC, except it isn't using an actual View in this limited example, I'd love to hear it. Controllers should be thin, models and services should be thick.

Re: MVC is dead, it's time to MOVE on

#159
MVC is nothing more then a pattern for component interactions allowing the separation of information. How you implement it is really up to the developer but this is the "starting" point for some and for many a guide.

Look at Django, it is often called MVT but yet it follows the MVC conventions. Maybe the language you are using is forcing you to add beef into your controllers hence the negative view of this pattern. But ultimately if your coding in Python you would be abstracting logic code out into your Models and Modules and only making references to them in the Controller.

Re: MVC is dead, it's time to MOVE on

#160

Earlier quoted context omitted.

> In a web application, the salary can be presented to the user through numerous different views - as a number on the screen (plain HTML), as a slider (jQuery UI slider), as a bar in a bar chart (using some charting library) as JSON encoded output, as XML....

no, those output types dont map back to the controller, they are not views.

Restful Apis often times can return JSON with key value pairs for subsequent actions in the form of name: URL. While you can't click on JSON, it's a "view" for the consumer application because it can follow back into the controller. The distinction is that a view doesn't necessarily need to be a human reading a screen, and can most certainly be another application.
Post reply on HN