12 ms·

MVC is dead, it's time to MOVE on

• nicholassmith 14y ago
  You know it's nice reading a criticism of something that has an alternative solution offered rather than just going "hey MVC is terrible and you're an idiot for using it". I do however think there's still great benefits to MVC, if you're shovelling code into controllers and can't make it work like it should then MVC is not the right design pattern for the project. Like every other pattern it'll only work when it works, but MOVE sounds like an interesting addition that I might have a play with.
  • mitchty 14y ago
    I was hoping for a few examples of where it does better than mvc to demonstrate where it may be applied over mvc.
  • jerf 14y ago
    MVC is terrible for web apps (in the original local GUI domain it's fine for some things), you aren't an idiot for using it because you're probably not actually using it but rather only something loosely inspired by it, and the solution is simply DRY. MVC at its best is simply one manifestation of DRY, but there's no real reason to get too stuck on it when with practice DRY is something you should just always be doing. If MVC falls out of that, great, but if not, so what? (The original MVC is actually useless for web apps because there is no client-server connection in it, and that profoundly changes everything. There's no point in trying to bash a GUI top-level design into a new client-server world, especially when DRY is just sitting there, waiting for you to use it.) MVC, MOVE, all the variants just obscure your vision from the underlying and far more important principle.
    • Xurinos 14y ago
      I suspect this is because most people do not actually understand what MVC is and how it applies to server-client relationships; in fact, the wikipedia article on MVC is slightly off on the subject, assuming one accepts the original Xerox description as a source. Try not to wrap the entire complicated application into one big MVC umbrella because that will just confuse. There are actually multiple processes involved, and each has its own MVC. The big epiphany for me was when I realized that the server has its own MVC, and the browser has its own MVC. The server's output is the View for the server and the Model for the browser. For a complex set of objects in a given Model, the final output of those objects is their View, and the consumer of that output uses it as a Model. In theory, any View can be a Model for the thing accepting the View, so in a complex system, you have a chain of MVCs. And one can further imagine that applets written in JavaScript have their own MVC unit. I work on complicated, large-data web apps sometimes daily. MVC has been a fine model for them and has kept my group's organization clean and modular.
      • saraid216 14y ago
        > 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."
        • Xurinos 14y ago
          Naturally, I meant nothing personal to you. Would a bug report suffice? ;)
        • wahnfrieden 14y ago
          This can be a really frustrating experience with articles where most people hold misconceptions about the concepts. I spent a few months off and on on the REST article and managed to clean it up a fair bit, but I was constantly working against militantly ignorant people. Last I checked it's somewhere between accurate and bullshit, one of the poorer resources for understanding either actual REST or more popular RPC style APIs.
        • mortenjorck 14y ago
          >"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."
          • saraid216 14y ago
            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.)
    • notJim 14y ago
      > MVC is terrible for web apps Can you expand more on this? I've used MVC for webapps quite a bit, and find it to work well.
      • andrzejkrzywda 14y ago
        It's more than a definition issue. You haven't used MVC, you have probably used Model2. The post we're discussing is about MVC. http://andrzejonsoftware.blogspot.com/2011/09/rails-is-not-mvc.html http://andrzejonsoftware.blogspot.com/2011/09/rails-is-not-m...
    • andrzejkrzywda 14y ago
      Thank you for this comment. I was slowly losing my faith in HN developers knowledge. Server MVC (Model2) is not the same as client MVC (the classic one). They are totally different architectures. Patterns that apply to one, don't apply to the other. You can't get MVC with Rails/Django/Struts. You can get a nice MVC with a Single Page Application or with a desktop app. A similar discussion was already here: http://news.ycombinator.com/item?id=3035549 http://news.ycombinator.com/item?id=3035549
      • nicholassmith 14y ago
        This times 9000. I've noticed a trend amongst developers to jump at patterns and spend all their time trying to shoehorn their project into it because someone vaguely respected mentioned it on Twitter. Patterns are great, but slavishly following them, and not understanding that there's often multiple patterns for different circumstances can lead to coding dragons.
  • larrybolt 14y ago
    I think this article goes even beyond the "is terrible and you're an idiot for using it", it actually "states" MVC is dead. Honestly I'm sick of reading all those "x is dead"-alike articles. Hey, if you believe the web PHP is dead, Java is dead, C is dead.. etc... Technologies, patterns, languages or structures don't die, in fact, if you really fancy you could write your application using C code and compiling it into asm, why not? If it works, perfect! There are enough examples out there where old technologie works. And I think people tend to be spending too much time thinking why something is imperfect, or how to do it better, instead of actually making stuff that rocks. If you really do have the need to improve something, prove it! Make a useable example, write a framework, library or new language if you really need to.
    • saraid216 14y ago
      > And I think people tend to be spending too much time thinking why something is imperfect, or how to do it better, instead of actually making stuff that rocks. I was with you until this. I think it's actually important to think about where flaws are and how improvements could be made. The literary critic Howard Bloom actually argues that many of the best creative works are agonistic: they take a previous masterpiece and say, "I could do better," and from that claim do. The produced work ends up being a response, saying, "That was good, but here's your mistake, here's how it can be done better, and look how well it turns out."
  • ascendant 14y ago
    MVC doesn't fit cleanly into the world of webapps, but it's still a lot better than business logic in view code, or monolithic classes than handle all HTTP interaction, etc. I've seen some really terrible Model 1 code in my lifetime.
• peter_l_downs 14y ago
  Are there any MOVE frameworks yet? I very much like the idea, but one of my favorite tests for "correctness" in a program is to use it to build something. Although it could be (and probably is) a reflection on my lack of knowledge, I find myself "fighting" with MVC frameworks like backbone whenever I try to use them. I would love to see if MOVE would be any better.
  • swalsh 14y ago
    I feel like you could still accomplish this with existing frameworks, though it'll be a bit of a hack. Perhaps split the controller in half, for instance LoginOperations and LoginEvents
  • wavephorm 14y ago
    I think the problem with most MVC frameworks is not the framework themselves, but that that the MVC design pattern should only be considered while refactoring existing working code. Starting right off the bat with a giant MVC boilerplate isn't necessary and may even be counter-productive. I write my code initially as one monolithic controller, and then refactor my code into an MVC pattern. It doesn't take that long to move functions from one object an other, and now you're working with an already-functioning piece of code rather than guessing how things might work later on.
    • peter_l_downs 14y ago
      So this could be the part where I'm not that great a programmer, but the I've had trouble creating apps from scratch with MVC, not just refactoring existing code.
      • alttab 14y ago
        MVC didn't really click for me until I wrote a non-trivial web application in PHP without it.
  • chaostheory 14y ago
    "Are there any MOVE frameworks yet? " I don't think so, but I feel that Grails may be the closest thing currently. It has a concept of a Service construct that feels like an Operation. Then again I could be completely wrong.
• vasco 14y ago
  This looks like a really good way to stop putting all your messy code into Controllers and start putting it into Operations. The problem with messy code or where it lives will not go away because you think about it differently, you just have to either hire better people or spend more time and money refactoring.
  • cirwin 14y ago
    The advantage of operations over controllers is the composability. Whereas controllers have a pretty undefined lifetime, operations are finished when they're done. This means that operations can use each other to get work done, a pattern you don't see with controllers.
    • alttab 14y ago
      You can build a set of composable methods that you can use in the controller.
• rorrr 14y ago
  So you renamed "controllers" to "operations".
  • trebor 14y ago
    No. An operation appears to be a one-off "action" rather than a collection of actions (like a controller).
    • alttab 14y ago
      This is a small difference. You can say that an operation is simply a controller with one method in it.
    • bradwestness 14y ago
      So basically he's just putting the controller methods in their own namespace. Which is all well and good, but I don't think anybody argues that all of your business logic has to be in the controller class for it to be considered MVC.
  • pestaa 14y ago
    It splits controllers into operations and events. Out of the three terminologies (state, representation, flow), the third one is arguably the most tangled. I find it healthy to refactor it into reusable chunks (operations) and event-driven flow management. The problem was, in my opinion, that operations should have not been put into controller units. It attracted more copy-paste solutions in my experience.
    • utilitron 14y ago
      What is the difference between that and adding a service layer to a MVC?
      • rcgs 14y ago
        There isn't, but then is MVC really MVC when you've added in another layer?
• netghost 14y ago
  Seems like a reasonable way to structure an application. It would be great to see a concrete example or two. The login example that is sketched out gets you partway there.
  • Bootvis 14y ago
    Yes, the proof of the pudding is in the eating. So: Do you haz teh codez? The idea in practice gives a much better idea of what the pros and cons are.
• kenperkins 14y ago
  I prefer the term "Services" over "Operations". Services is where the logic of your application should live, and services should be HTTP (or any protocol) agnostic. They should only speak in models and native types, and should abstract all of your logic away from your controllers and models. This leaves the controllers as a thin http handling layer that parses inputs and then lets the service handle the work. The response from the service is then transformed appropriately (JSON, HTML, etc) and sent back to the caller. Just my $0.02
  • Yhippa 14y ago
    "MSVE" just doesn't have the same ring to it :-)
• alttab 14y ago
  This is certainly interesting. I like the event based model. Here are my thoughts: If your controllers are getting fat and spaghetti like, I wouldn't blame MVC. There are many patterns one can use that are compatible with MVC without going to a completely different architecture. For instance, if you need to encapsulate multi-model interaction you can create a presenter abstraction that the controller simply calls into. Just because there is a bunch of code that ends up in the controller because "you don't know where to put it" doesn't mean there isn't a better place to put it without re-designing the entire application. Another thing is while I love the data-binding event deal, this really only works for client-side frameworks like Backbone. Server-side kinda goes at the window, but I suppose you could add a framework that piped event signals in the response from changes that occurred in the ORM layer (although this further couples components). I'm not convinced that separating the data from the methods that operate is a great idea unless you want to go purely functional. Doing this clearly breaks encapsulation, throws any notion of OOP out the window, and still binds the "operations" too closely to the data. Generally speaking, the data is useless without the operations and vice versa. So the real difference between MOVE and MVC, at least according to this article, is that models are no longer useful on their own, the controllers aka "operations" know everything about how to manipulate models (it shouldn't), and models generate events which are only consumed by views, which makes no sense if you wanted to use the model on its own (but you can't without your operations). Generally speaking, the model should MODEL something. That includes data and behavior. Without both, you have a database, and a set of operations kinda like a C library but only because OOP hadn't been invented yet. In my mind this further couples all of the components because it actually increases the reliance on each other for them to be useful. MVC isn't dead. There is a good chance you are using it wrong. I highly suggest Rails Antipatterns. While it is specific to Rails, it works for MVC in general. http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison-Wesley-Professional/dp/0321604814 http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison... edit: spelling
  • deleted 14y ago
    [deleted]
  • pestaa 14y ago
    Sorry, but data-bound events are not useless in server context. It might be exactly what we need when fat controllers go out of control. Perhaps you meant they are too much of a complication if taken too far to work across all concurrent requests? Binding data and behavior together breaks the rule of single responsibility, which I believe is far worse than designing separate roles in sepearate components that work together. Models should model the data structure only, if you need a presentation abstraction anyway for multi-model operations. Why not go the extra mile and use this abstraction level for all operations? It is a false dichotomy that you go either full-OOP or purely functionaly. Models wrap knowledge as the article suggests, That means that, in addition to getters and setters, they might contain functions that let you check "is this the user's password?". I envision these methods to work on a single attribute, whereas multi-attribute and multi-model business logic belongs to operations. MVC isn't dead, but it was a local maximum OOP gave us. Event-driven development seems to raise and work well with objects and datasets.
• benihana 14y ago
  Seems like the Operation layer is a combination of controllers and business logic, which feels like a bad idea to me. If the models only wrap knowledge, but don't do any work, then it's the part of the Operation to both decide what to show and also get it in the correct format to show. This seems like it's doing too much and is analogous to the MVC problem of really fat controllers.
  • goblin89 14y ago
    On a flip side you can get models that do too much. At one point I had a method on a model that, in order to get data into correct format, just went and rendered a [Django] template. It came to that naturally, the line is thin, and I now prefer to err on the side of models doing too little. > it's the part of the Operation to both decide what to show and also get it in the correct format to show Did you mean Views, not Operations, here? Or maybe I'm missing something.
  • EdwardTattsyrup 14y ago
    I think it's unfortunate that the author chose to use the word "model" in MOVE. It appears that the "model" in MOVE is not the same thing as it is in MVC. That risks confusing a lot of people.
• tubbo 14y ago
  Can't wait for the first MOVE framework to come out: "Mumia"
• detay 14y ago
  http://xkcd.com/927/ http://xkcd.com/927/
• scrame 14y ago
  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. In Java/Spring-MVC, there is a typical class hierarchy of Controller -> Manager/Service -> DAO. The extra level of indirection is a very handy place to put business logic, then each class in the tier has a dedicated function: Controller -- Parses input, delegates the action and returns the response (rendered by the view). Manager -- Handles sanitized data, encapsulates business logic and makes calls into the Model / Data layer. DAO -- Interfaces with the data store, makes sure only good data goes in, and appropriate responses are returned. This approach doesn't seem to offer anything more than that, except for putting a label on the messaging between subsystems, but those operations are not well defined (at least in this piece), and seem like another nebulous way to bury logic. It seems like this problem has arisen from a rather narrow reading of what an MVC system should be, as in, not having utility libraries because they aren't strictly an M a V or a C. *edit: formatting.
  • edwinnathaniel 14y ago
    This article reminds me of Struts2 http://en.wikipedia.org/wiki/Apache_Struts http://en.wikipedia.org/wiki/Apache_Struts MVC with "action" (or event, similar semantics). Speaking of Java/Spring-MVC approach, I tend to have a mix approach of Service and Repository (since DAO seems to be getting a lot of bad-rep, time to pick a new name :D). Controller -> Service (SOAP) or Resource (REST) [although Resource could simply forward to Service as well) or Controller -> Repository (for specific entity that requires no interaction with other entities) Unfortunately the Service layer is necessary in the situation where there are 2 or more domain models need to interact with each other. This seems to help writing test-automations by splitting the tests into 2 categories: 1) End-to-End w/ mock repository 2) Integration only at Repository level using in-memory DB (Derby, H2) By doing this, we were able to speed up the test significantly. I believe in Rails, you're tied with ActiveRecord and would require real database (be it SQLite3). There may be open source libraries that can intercept AR calls and re-route it to either fake DB or just simply fake 'em all, but not sure how popular/complete they are.
• pkaler 14y ago
  In the Objective-C/Cocoa world, Operations are encapsulated using the Receptionist Pattern. http://developer.apple.com/library/mac/#documentation/General/Conceptual/CocoaEncyclopedia/ReceptionistPattern/ReceptionistPattern.html http://developer.apple.com/library/mac/#documentation/Genera... And Events are handled with a combination of Key-Value Observing and UI binding. http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/KeyValueObserving/KeyValueObserving.html http://developer.apple.com/library/mac/#documentation/Cocoa/... Controllers still exist but the design of a program is easier to reason about if everything that mutates data is pulled out of the controller. UI changes must be made on the main queue, but the above design helps pull out model changes, network requests, etc on to background queues.
• tree_of_item 14y ago
  Does anyone else not really get "MVC"? It seems like every person has their own idea of what it is and no two frameworks can agree on what the necessary parts are. I get the feeling MVC is mostly a bunch of handwaving about separation of concerns, motherhood, and apple pie.
  • wavephorm 14y ago
    MVC is just a design pattern, a way to organize code, it's not a religion.
    • tree_of_item 14y ago
      I wouldn't like it to be a religion! I'd just like some precision. Design patterns point to a large region of possible configurations, so to say something is "MVC" isn't saying very much.
  • rch 14y ago
    For a succinct description that also explains the origins of some of the discrepancies: http://c2.com/cgi/wiki?ModelViewController http://c2.com/cgi/wiki?ModelViewController
  • asolove 14y ago
    The original MVC architecture was for GUI interfaces in Smalltalk. It was so helpful a design pattern it was borrowed for use in request/response web application, where naturally the use of each part was very different. If you really want to "get" the original MVC, see the classic book "Smalltalk, Objects, and Design" [1] which explains MVC and other OO architectures as well as the principles behind them, which might guide you to picking an appropriate structure for applications that don't fit the GUI/MVC paradigm. [1] http://www.amazon.com/Smalltalk-Objects-Design-Chamond-Liu/dp/1583484906 http://www.amazon.com/Smalltalk-Objects-Design-Chamond-Liu/d...
    • alttab 14y ago
      My original implementation of Mvc was writing a game of connect 4 in java. There was a board model. There were two views. One graphical, and one command line. You could update both views by clicking your next move on the graphical board, or putting input on the command line. Once the model was updated, the controller would update any view that was listening on it.
• sakopov 14y ago
  Isn't this what CQRS attempts to do? [CQRS]: http://martinfowler.com/bliki/CQRS.html http://martinfowler.com/bliki/CQRS.html
  • lucisferre 14y ago
    Sort of but nt quite, it feels much more like data-context-interactions. Really this doesnt kill MVC at all but extends and enhances it.
• jhaile 14y ago
  My controllers have one function for each operation. Oh yeah, and they talk to each other using events...um...
• jasim 14y ago
  MVC is not dead. It has its warts, but there still is a strong developer community who build applications using MVC - through MVC based frameworks, and also by handrolling implementations that are an approximation of MVC. As long as there are enough people using it, MVC can't be pronounced 'dead'. As to MOVE, the issue that the author points as the problem with Controllers in MVC is that'controllers are nice self-contained bits of.. what?'. At some point people will start asking these questions about 'Operations' and 'Events'. What would you classify as an 'event' vs an 'operation'. Some mature Rails projects that I've seen already uses this paradigm - there is an internal synchronous pub/sub event listener to which messages can be pushed by both the controller and the model. Even then, there is always a question of where to put what. Some answers are very clear - like an audit log which is only a side effect. But it is not the case always. The author is trying to solve this 'classification' problem by giving us a more granular model. This can help to a certain degree - but there will be some point where even this wont help us. At that point we can choose go to a finer granularity, or ask the question whether all this extra organization is worth the hassle? Abstractions are not without a cost. Some abstractions are too essential for any project. Some abstractions are nice to have. But all of them have a cost. In the case of MVC, the cost of the extra organization is paid many times over by the increased maintainability of the application. But given the number of components the MOVE paradigm advocates, I'm doubtful whether the added organization will be worth the cost. I agree with what DHH said on a recent podcast - it is easy to talk about concepts in abstract and they can look really good. But what changes the game is a real implementation and being able to contrast the code 'before' the change and 'after' the change. This is not feasible all the time - some things have to go through the ideation and a slow testing phase. But at the least, I'm looking forward to see a non-trivial application that uses this paradigm. I'm ready to try imagining how it would have looked in MVC and decide whether the extra organization is worth it.
• deleted 14y ago
  [deleted]
• jaybill 14y ago
  I don't know. This is essentially saying that the way to solve problems is to add additional layers of abstraction. If you want to see a bunch of examples of why that's a bad idea, take a look at any J2EE application. RAPHT (https://github.com/DanielWaterworth/Raphters/blob/master/RAPHT https://github.com/DanielWaterworth/Raphters/blob/master/RAP...) attempts to something similar (adding more layers of abstraction to MVC) but I have the same problem with that. If we were really understood the problem we'd have come up with a way to make things simpler, not more complicated. I think the real problem is that MVC is understood by different people to mean different things but they think they're talking about the SAME thing. Back end developers tend to think of the view layer as a trivial thing ("It's just HTML and Javascript! How hard can that be?") and front end developers tend to think of the model layer as trivial. ("Look, my backbone.js code is handing out and consuming JSON, how hard can it be to persist that?")
• emmett 14y ago
  When I read suggested code where each class has one "process" or "run" method, I think that someone who lives in an object-oriented world has reinvented functional programming.
• ary 14y ago
  Arguably Cocoa and Cocoa Touch already have this with the responder chain and notifications.
• beberlei 14y ago
  Very spot on explanation of what is circulating in my head for months now. This seems to relate to the Data-Context-Interaction movement and what Bob Martin calls Entity-Boundary-Interactor pattern in his latest talks.
• agumonkey 14y ago
  For the curious, read the original papers from R.Trygve : http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html
• ap22213 14y ago
  I'm willing to try it out. I usually get around the cited issues through dependency injection into the model. That is, instead of placing large amounts of logic in the controller, I let the model hold the logic. In a naive implementation, this may couple the model to things it shouldn't be coupled to. So, to avoid the model coupling to infrastructure resources (say, storage), I let the controller inject those objects into the model, as needed. But, I realize that that's an architect-y, OO kind of way to do it that requires some background knowledge which can may obfuscate the code. So, I'm all about making things easier for everyone. As others have mentioned, it'd be useful to have a more sophisticated example.
• grandalf 14y ago
  Operations are just a temporary stop on the road to functional programming.
• Alexandervn 14y ago
  Addy Osmani has a nice excercition [1] on the history of MVC in Developing Backbone.js Applications, where he states: "Developers are sometimes surprised when they learn that the Observer pattern (nowadays commonly implemented as a Publish/Subscribe system) was included as a part of MVC's architecture decades ago. In Smalltalk-80's MVC, the View and Controller both observe the Model: anytime the Model changes, the Views react." So, not really new actually. [1]: http://addyosmani.github.com/backbone-fundamentals/#mvc http://addyosmani.github.com/backbone-fundamentals/#mvc
• rossjudson 14y ago
  The interesting part of this is the resemblance of hierarchical operations to Erlang supervisor hierarchies, without explicitly pointing that out. In fact, the whole thing feels kind of Actor-like.
• guelo 14y ago
  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 move from MySQL to Memcached. Using events for everything has appeal but my experience is that the added synchronicity problems creates unneeded complexity and makes reasoning through the logic and debugging hard.
  • bradwestness 14y ago
    Yeah, I've always used MVC with a repository pattern for handling Model operations. The controller is still calling the operations here, and handling events triggered by the user. The O and E in MOVE sounds effectively the same as the C in MVC. Model objects are generally just POCOs (or POJOs, or whatever) and should not know about their storage mechanism or dealing with user events. Sounds like he's basically been doing MVC wrong, and thinks MOVE is something new, when really it's just closer to the way MVC should be done in the first place.
  • rbanffy 14y ago
    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 with a completely different model.
    • jorgenhorstink 14y ago
      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: <?php class AuthController extends Controller { public function __construct(Request $request) { $this->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.
• rglover 14y ago
  Wow. As a designer who recently took the plunge into learning MVC (via Ruby/Rails), this is incredibly easy to understand. It took a bit of thinking to understand MVC but for some reason, separating out the concept of operations/events makes it blatantly obvious. Now an important question: how would you practically implement this? Would this dicate a separate framework/language altogether or something else (I have a cursory knowledge of development, so play nice)? Edit Just noticed the footnote at the bottom of the article linking to these: https://github.com/bitlove/objectify https://github.com/bitlove/objectify and http://collectiveidea.com/blog/archives/2012/06/28/wheres-your-business-logic/ http://collectiveidea.com/blog/archives/2012/06/28/wheres-yo...
• wissler 14y ago
  I've always thought MVC was a joke played on gullible software engineers, kinda like this: http://en.wikipedia.org/wiki/Sokal_affair http://en.wikipedia.org/wiki/Sokal_affair
• Erwin 14y ago
  An interesting new pattern here (from the creator of MVC) is DCI: http://en.wikipedia.org/wiki/Data,_Context,_and_Interaction http://en.wikipedia.org/wiki/Data,_Context,_and_Interaction Essentially it's a way to move code where multiple objects collaborate to achieve something into its own separate class (Context). However when executing in a context, each involved object takes on a "Role" which grants its additional methods specific to this context.
  • mempko 14y ago
    Thank you sir. I was worried nobody would mention DCI. I believe DCI is a far better solution to the MVC problem of dealing with 'algorithms' than MOVE. MOVE almost seems to be MVC plus goto.
• martian 14y ago
  This pattern is fantastic. We use a similar pattern that we internally call "Actions". An Action, in our parlance, is similar to the Command pattern from the Gang of Four. It can be invoked from anywhere and performs a single state change on a single model, or even multiple models (if several need to be updated at the same time, in the same transaction). Separating Actions from Models was a huge step in writing readable code, and it's immediately clear what is happening in the system at any given time. Any Action can invoke any number of "child" actions, as well, to maintain encapsulation. For example: when a user registers on the site, we trigger a RegisterUser action, which in turn calls a CreateUser action and a LoginUser action. Basically, we took any complicated method on our models and turned them into Action classes. Common concepts like database transactions, logging, event tracking, and so forth, can now be abstracted away, and don't need to be re-implemented in each model class. It's a huge productivity increase and a real win for software engineering. I highly recommend this general approach to any large software system, and I'm grateful that we're all experimenting with things beyond MVC.
• notspamguy 14y ago
  MOVE sounds an awful lot like JSF.
• hmans 14y ago
  lol, objectify.
• deleted 14y ago
  [deleted]
• drostie 14y ago
  If your controller has too much logic you should really consider putting more of it in your model and view. Maybe I don't understand MVC, and you all can tell me How Wrong I Am, but here's how I understand MVC at present: Your Model is a public API, a Service Gateway -- and it should do a couple of things in principle. The first is that it should be able to manage a list of subscribed view/controllers, and push updates out to them -- this was difficult with Web 2.0 but we're now moving to systems where this is considered normal. The second is that it should define a set of API commands which change that state and push out those subscriptions. That second bit is crucial, it's the difference between writing assembly and Python. If you have logic in your controller then it's probably because your model does not expose certain high-level concepts which your controller would use directly, so you're taking data from the model and building a higher-order model in your controller, before you operate on it. It helps me to remember that in Smalltalk the idea was to always have <view|controller> pairs. They were always the same object split in two; each view had its own controller and vice versa. The controller is supposed to be input-oriented and the view is supposed to be output-oriented; the model says "hey, X changed" and the view updates what X looks like; the user clicks on X and the controller sends a signal to the view to change some more, the user erases X and the controller sends this request to the model, which will update the view when the request is complete. Viewed this way it's really hard to see what the difference is supposed to be between MVC and MOVE. Clearly the messages in MVC are the Events in MOVE. Most of the controller logic has been pushed into the View, which should now handle input actions. Data cannot be dynamically pushed from the Model to the View because this is of course a Web 2.0 technology (pre-cometcasting, pre-websockets). The Operation sits in a grey area, implementing higher-order abstractions from the lower-order model. Maybe we could do better with a hybrid, because the idea of decoupling subscriptions from the public API might actually be a good idea, in line with the Clojure philosophy that things should be de-complected into their simplest representations. But if I understand MVC right, then I don't see why you've got all your business logic in your controller. Heck, the View is supposed to be client-side, why isn't your Controller client side? Or if it is, and you have all this business logic in it, why are you trusting the client to do your business logic? Your gripes with MVC don't make sense to me.
  • stonemetal 14y ago
• vtry 14y ago
  Try AngularJS, that's MVC done right.
• dougabug 14y ago
  I agree that the controller abstraction is a bit ambiguous, certainly to the degree that MVC means different things to different people. I thought that the article would be pure flamebait, but actually it does seem to be more precise in its terminology, and captures more closely how I generally design software systems.
• arms 14y ago
  I'd be interested to know what language(s) the author is using for these MOVE applications. I primarily use PHP, and have gotten in the habit of using a service layer to handle business operations. I've found that it's worked extremely well, and so far does not seem restrictive. It's let me clean up my controllers and models quite nicely. It's been awhile since I've used the RobotLegs Actionscript framework, but its 'implementation' of the MVC pattern seems awfully close to MOVE. Overall, I think the author makes a good case of how to improve MVC application development, regardless of whether the name should change or not :)
• rco8786 14y ago
  Honestly it seems nearly identical with MVC except you call Controllers Events and Operations are just your business/data layer logic.
• moe 14y ago
  It's amusing how the agile crowd slowly goes through the same learning curve that the java-guys rode 10 years ago. That's a good thing, though. They're at the verge of rediscovering SOA now and there's hope this incarnation will be less plagued by IOC-fluff and boilerplate, simply because the involved people have more of a hacking and less of an engineering background. I, for one, am looking forward to the "great shattering of Rails".
  • krsunny 14y ago
    How is SOA like teenage sex? Everyone thinks everyone else is doing it, few are actually doing it and the ones that ARE doing it are doing it wrong.
• Produce 14y ago
  I stopped reading right around here: >the problem with MVC as given is that you end up stuffing too much code into your controllers, because you don't know where else to put it. What was that? You stuff all of your logic into controllers then claim that MVC is broken? Your ugly face is broken. Uglyface.
• jaaron 14y ago
  MVC, more than other design patterns, is horribly abused. Developers should keep in mind its GUI roots. Here's my "is it MVC?" litmus test: How much of my code survives if I drastically change the view? For example, if I want to switch to a new desktop, web or text console interface, can I reuse much of the application? Of course, architecture changes this significantly (particularly web architecture), but still, if I cannot swap out the view, then I'm losing out on one of the significant advantages of an MVC architecture. One way to make sure this works is to start with 2 views from the beginning - the view you're actually going to ship, and a headless view for tests.
  • jshen 14y ago
    my rails apps pass this test with flying colors. Nearly all of my end points have at least 3 views. 1 for html, 1 for json (often used for ajax calls), and 1 for rss/atom.
    • deleted 14y ago
      [deleted]
    • blahbap 14y ago
      JSON and RSS views don't make sense - in MVC, views are visual representations of data (the model). Views are how the user percieves the application. JSON and RSS are just different methods for representing data to be communicated to other systems.
      • blowski 14y ago
        Users are not necessarily human - they can be search engines, API consumers, etc.
        • blahbap 14y ago
          In the context of MVC, a user is a human being - describing JSON and RSS services as "views" totally misses the point. Quote from the inventor of MVC, Trygve Reenskaug: "The essential purpose of MVC is to bridge the gap between the human user's mental model and the digital model that exists in the computer."
• TylerE 14y ago
  For the web, I find Lift's "View-First" setup much compelling, and easier. The issue I have with traditional web-framework MVC is that it assumes that each URL associates with one controller, which I've found to be very straightjacket-esque. Often the pages I'm building have many separate bits of functionality present, from simple stuff like a login box, numerous widgets, and then the main thing the page is about. In lift, each URL maps onto a view, which will contain the templating code for that page, including perhaps inheritance to pull in an overall template, and then will contain one or more (and perhaps MANY) snippet invocations. A snippet in Lift is kind of sort of like a controller method. It takes the contents of it's template tag as input, and as output returns a transformed document tree, using what ever resources (models, web service calls, calling out to other classes, etc) it wants to do that. If you write the snippets in a general way, binding text off of IDs, this allows you to get different outputs for the same data, depending on how you call the snippet - it's like passing a partial template in as a closure. Very different but powerful - the snippet handles the LOGIC, but only abstractly the templating. It's a very powerful paradigm - it frees you from the MVC straightjacket, since you can arrange and organize your code however you like, but forces very strict separation of concerns - it forces you to compartmentalize your business logic, but doesn't force you to do it a certain way. Lift does really cool stuff with your xHTML/HTML5 templates too - it's truly operating on a server-side DOM tree, none of this is textual substitution. http://www.assembla.com/spaces/liftweb/wiki/Templates_and_Binding http://www.assembla.com/spaces/liftweb/wiki/Templates_and_Bi... for more info.
  • SkyMarshal 14y ago
    Second that about Lift too. It's basically server-side jQuery. Instead of parsing templates as one big string, it does DOM transforms on sub-trees. Parallel, independent, lazy-loading transforms using an Actor for each for each Snippet/subtree. Really awesome model. Also, Twitter's recent 180 on shifting some processing from the client back to the server [1] suggests a server-oriented framework like Lift's is worth considering, despite the hype and excitement around client-heavy Rich Web Apps. Lift does the API-consuming rich client model as well, but its uniqueness is the DOM transform stuff. Very different mental model than MVC and hard to get started with for some because of that, but here's a great bit of advice on best practices I came across recently (especially the part about pretty everything being done via either LiftRules or the S object) [2]. 1. http://engineering.twitter.com/2012/05/improving-performance-on-twittercom.html http://engineering.twitter.com/2012/05/improving-performance... 2. http://www.quora.com/Lift-web-framework/What-are-the-best-practices-for-using-Lift http://www.quora.com/Lift-web-framework/What-are-the-best-pr...
• namank 14y ago
  Umm...what? What do you think helpers are in PHP MVC frameworks? They are code blocks that should not go in controllers but are required; like a password generator or reformatting for print command. Go use Symfony to see how events and MVC mash up together. They do a good job in there. Author's next post will be about including services for controllers/helpers/actions that are called more frequently. Once again, Mr. Author, check the PHP framework called Symfony.
• smoody 14y ago
  I've replaced MVC with VAM -- View->API->Model. I believe it's best to always code the "operations" layer as an API layer. The API always acts on models. Very similar to operations in MOVE, but it clarifies the goals of the layer.
• zacharyvoase 14y ago
  > I don't wish to be misunderstood as implying that MVC is bad […] Since it was invented however, new programming techniques have become popular. This doesn't make any sense to me. The first problem is the blatant argumentum ad populum—just because other things are popular right now doesn't mean they're better. The second problem is: I simply do not agree that we have new technologies that are so radically different and empowering from those that were available when MVC was invented. Indeed, Smalltalk (the language in which MVC was conceived) has late binding, dynamic typing and code blocks. I still think ‘modern’ scripting languages are playing catch-up with Smalltalk and LISP in terms of power, performance and clarity of expression. Trygve Reenskaug (the inventor of MVC) later went on to develop DCI, a system which complements MVC, rather than replacing it wholesale. I'd recommend reading the Wikipedia page for more info, it's a coherent proposal and it seems to require the creation of far fewer classes and objects: http://en.wikipedia.org/wiki/Data,_context_and_interaction http://en.wikipedia.org/wiki/Data,_context_and_interaction
• deleted 14y ago
  [deleted]
• Spearchucker 14y ago
  Interesting post. I've spent the last few years on an piece of software where the model and controller must be reusable between desktop, phone and tablet. I started with a layered approach. Then I moved to MVC. After that I discovered MVVM. I finally ended up with an MVVM/Naked Objects hybrid. The result is views that make changes to the model via command bindings, and respond to changes in the model via event bindings. The application (aka controller) is similarly bound to the model, and contains all business logic. It's clean, easy to maintain, and easy to test against and debug. The views are different for each platform (desktop, phone and tablet), the model and application are re-used as-is. I guess my point is that none of these approaches (MVC/MVVM/MVP/etc.) are bad. Each is good within a pretty small scenario window. The trick, probably learnt through experience, is knowning when to use which.
• stcredzero 14y ago
  I'm going to go out on a limb here. With a pattern like MVC, where developers implement it again and again, and many of these are junior devs, it's highly likely that people who don't entirely understand the pattern are going to be adding code. The correct use of the pattern is going to get diluted, and certain classes are going to get overstuffed with code that often turns into spaghetti code. I'm not so sure this is the fault of the junior developers. If there is one "obvious" place to expediently stuff code to implement new functionality then this is actually the fault of original designers. I don't know of any pattern for building applications that doesn't fall into this trap, but I think that one which escapes it is possible through some trick of code organization and programming language technology.
• pmb 14y ago
  Show me the code. Before I believe this, I'll need to see a codebase that uses MOVE and not MVC and manages to do things which are not easy in MVC. It's find to rant and rail against old patterns, but patterns are descriptive, not prescriptive. Once you see a solution that has the same "shape" in a few different contexts, you might have found a pattern. This puts the cart before the horse by proposing the pattern before it has been actually used.
• EGreg 14y ago
  So basically Controller has Operations and Events Kind of like in MacOS it has methods and delegates?
• Avalaxy 14y ago
  The author probably never heard about the 'service layer' pattern. The problem that 'MOVE' is trying to solve is a non-existing one. If you're stuffing all your logic in your controller, you're doing it wrong. The logic should be in the service layer, that's how it has always been.
• specialist 14y ago
  There is no MVC. A design pattern is a reusable solution to problem, given a certain context (set of constraints). My design pattern study group iterated over the Gang of Four book 3 times, please many others. The MVC sessions were the least constructive. No two people could agree on what is and isn't MVC. Or MVP. No, you're not doing it right. Oh, MVC can only be done "correctly" using Smalltalk. Yadda yadda yadda. I can't even begin to discuss "MVC web frameworks". Huh? Methinks the only reason for "MVC" is to justify Spring, inversion of control, containers, dependency injection, annotations, and all that other useless enterprisey J2EE-esque shovelware. I agree with jerf's statement (upthread) that devs should worry more about DRY than MVC.
  • fadzlan 14y ago
    There is MVC. Its just a concept, unlike those design patterns from GoF which are specific. Models are just data, View are just representations and Controllers are just endpoints. You can program your own way in your language, and if you can categorize your code as such, you can argue it is MVC. And of course, because its just a concept, anyone in the world can argue why your implementation is not MVC as well. No, MVC is not the reason to justify Spring, inversion of control, containers, dependency injection, annotation and all other "enterprisey J2EE-esque shovelware" as you mentioned. MVC has been around since SmallTalk (you know, before even Java...). Heck, you even get MVC in Rails. You see Spring in Rails? Dependency Injections? Annotations? Of course not, since I could not even begin to think they are related.
    • specialist 14y ago
      Of course not, since I could not even begin to think [Rails and Spring] are related. Sure they are. Spring is the Java community's effort to get some of that dynamic programming goodness (ahem). Rails is the Ruby community's effort to reproduce the unmaintainable mess of J2EE. You couldn't have one without the other.
  • kalininalex 14y ago
    You are right, MVC means different things to different people, so whenever someone says "MVC" I try to stop them right there and ask to explain what exactly they mean before proceeding any further. Martin Fowler has an excellent write up on the history of MVC and related patterns (and resulting confusion) in http://martinfowler.com/eaaDev/uiArchs.html http://martinfowler.com/eaaDev/uiArchs.html.
• rickmb 14y ago
  "you end up stuffing too much code into your controllers, because you don't know where else to put it" And that wouldn't happen to have anything to do with the fact that "you" either don't know any other patterns or solutions besides MVC, or are under the impression that using MVC somehow forbids you to use other patterns? Not to mention the fact that the definition of MVC that the author uses is false (in a way that describes MVC as more simplistic and limited than it truly is), but after so many years I'm not even going to argue with that any more. Just fucking Google it. tl;dr: Those who cannot learn from history are doomed to repeat it.
  • einhverfr 14y ago
    ummm... one nitpick..... Everyone repeats history. Some repeat the good parts. Others repeat the bad parts. Learning from history allows us to try to stop repeating the bad parts and do better with the good parts.
• twelvechairs 14y ago
  > In a MOVE application models only wrap knowledge. That means that, in addition to getters and setters, they might contain functions that let you check "is this the user's password?", but they don't contain functions that let you save them to a database or upload them to an external API. That would be the job of an operation. I cant understand the distinction between a 'setter' (stated here as part of the MOVE 'model') and 'functions that let you save... to a database or upload... to an external API' (stated here as part of the MOVE 'operations'). I would understand the logic a lot more if the 'model' excluded 'setters' entirely and just included 'queries' (which don't change the underlying data set) as opposed to 'commands'/'setters' (which do...). As it is I'm not sure where the line is between 'operations' and 'model' except for the use-cases that have been explicitly stated.
• azylman 14y ago
  Does anyone else think that it's weird for the model to be sending events directly to the view and have the view listening for those? That seems like something that should be going to the "operation tree" and having that push changes to the view.
• azylman 14y ago
  Does anyone else think that it's weird for the model to be sending events directly to the view and have the view listening for those? That seems like something that should be going to the "operation tree" and having that push changes to the view.
• brendoncrawford 14y ago
  This seems to be pretty much the same as MVC, where "Operations" are controllers and "Events" are essentially routes. Am I missing something?
• Androsynth 14y ago
  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 controllers. This is understandable because there is no observer pattern and therefore the models don't have nearly the power they do in real MVC. Heres a great explanation of the MVC[1]: In a nutshell the classic MVC architecture work like this. There is a model that is at the heart of the whole thing. If the model changes, it notifies its observers that a change occurred. The view is the stuff you can see and the view observes the model. When the view is notified that the model has changed, the view changes its appearance. The user can interact with the view (e.g. clicking stuff) but the view doesn’t know what to do. So the view tells the controller what the user did and assumes the controller knows what to do. The controller appropriately changes the model. And around and around it goes. [1] http://michaux.ca/articles/mvc-architecture-for-javascript-applications http://michaux.ca/articles/mvc-architecture-for-javascript-a...
  • revaaron 14y ago
    My thoughts exactly. Having used MVC for many years, and in the environment where it was invented (Smalltalk-80), I couldn't help but wonder why he was reinventing MVC while thinking he was criticizing it.
  • kenster07 14y ago
    In practical terms, those observers would have to live in the controller, or there would be coupling between the model and views.
    • Androsynth 14y ago
      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.
• tieTYT 14y ago
  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.
  • mattgreenrocks 14y ago
    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.
    • alttab 14y ago
      The one thing I care about the most is architecture and system design. These conversations are largely absent and developers can go years without acquiring a pallete for this type of discussion. I wish it was discussed more as a lot of the cost of maintenance could be cut down if spaghetti were properly avoided.
• lectrick 14y ago
  > but the problem with MVC as given is that you end up stuffing too much code into your controllers, because you don't know where else to put it. What the hell is he talking about? Has he never worked with Fat Model™ design?
• serbrech 14y ago
  "the "currentUser" model will emit an event to notify your application that it has changed" That sounds like more than just wrapping knowledge to me. Also, why do you absolutely want to fit everything into a framework? Or a pattern? Business logic goes into your domain models. Don't mix your business logic with your framework, that's about it...
• deleted 14y ago
  [deleted]
• azat_co 14y ago
  Old issues: where to put business logic. Controller, Model, maybe even view? Why just don't use abstraction layer for business logic? Most people do it already. Should we call it Operations?
• semerda 14y ago
  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.
• rdudekul 14y ago
  As a Node.js developer and a former Rails/MVC developer, MOVE does make a lot of sense. I will be waiting for a MOVE Node.js framework with good examples to emulate/use in my Node apps.
• shadowmint 14y ago
  meh. Doesn't address any of the actual issues with writing an MVC web application. MVC -> Views are templates, Controllers are HTTP server end point bindings and Model is everything else. Rookie mistake; put logic in controller actions. No! This is a terrible idea: your controller should never do more than: parse input, apply update to some model object, generate response view model. 'Model' does not mean 'Something that serializes and goes into a database'. It means everything else. The entire state and associated classes that manipulate that state. That's where these operations from MOVE exist. I mean, if you want to critize MVC (especially some popular frameworks...), go for it, but I'd be much more interested to hear how a new approach addresses: - What about all that javascript / flash / etc? Where does that fit in? - How do you effectively test controllers and views?
• modarts 14y ago
  How is this different from MVVM? His "events" are basically a ViewModel that is "observable" (generates an event when the underlying data changes, which the View listens for.)
• cbsmith 14y ago
  > Without closures (or anonymous blocks) event binding can be very tedious; and without deferrables (also known as deferreds or promises) the idea of treating individual operations as objects in their own right doesn't make much sense. Of course, MVC was developed and popularized on Smalltalk.... which had both of these notions...
• blakecaldwell 14y ago
  In addition, operations fit nicely into queues, and make undo easier. That is, a rename operation can queue up an inverse rename operation for its undo.
• shasty 14y ago
  Sorry, composable operations and models firing events is bullshit. The article is somewhat correct in that true MVC is dead in practice, however, service oriented architectures have already filled this void. Eventing is HORRIBLE. Regardless of the source, but models especially are not the place to be firing events. This was all tried years ago. Before writing an article purporting to replace a foundational concept in application development maybe do a little more research into what the actual practical solutions to these factoring problems are.
• joshontheweb 14y ago
  I think this is a really interesting idea, it would be cool to have a sample app to look at implementing your ideas.
• shellox 14y ago
  The site layout looks really great. It looks much better than the classical style for articles in the web.
• j_col 14y ago
  With regard to the "is dead" proclamation in this title, this comment from a previous commenter sums up my feeling perfectly: http://news.ycombinator.com/item?id=554397 http://news.ycombinator.com/item?id=554397 Once I see "X is dead" in a article title, I stop reading.
• michaelochurch 14y ago
  I like this. I'm not a UI expert in the least, but I've always felt that the "controllers" component was a bit ill-defined. It seems that the MVC division comes from a time when GUIs were for single-agent, deterministic desktop apps like calculators. In a world where "social" apps are increasingly important (and this time I use "social" non-pejoratively, because even if 99% of "social" is crap, the other 1% is damn important) and notifications need a first-class status, MOVE (the separation between operations, which are agent-initiated, and events, which are observed and can come from anywhere) makes sense.
• mempko 14y ago
  The inventor of MVC Trygve Reenskaug understood the problem a long time ago and invented DCI as a complement http://j.mp/MskKMx http://j.mp/MskKMx
• arunoda 14y ago
  There is no new here. You have a point here mvc need some upgrades. But it is not dead. You simply divide controller into 2 parts. 1. Events 2. Operations I too find event also can be think as a router. The title is bad. This is not new. But a good useful practise.
• arunoda 14y ago
  I say MVC is not dead. I just said it :) http://goo.gl/kvs7t http://goo.gl/kvs7t