Live data from Hacker News

Are we doing MVC wrong?

withouttheloop.com

1–10 of 25 posts

Re: Are we doing MVC wrong?

#2
MVC is not a dogma, it is a no-brainer instruction to make 90% of programming fruits less miserable. I usually end up with something like Views-Composers-Handlers-Routes-Libs etc. And this can vary from project to project.

Re: Are we doing MVC wrong?

#3
My issue here is that BorrowABook is a verb. This isn't a model class, and in my understanding of OOP, doesn't really deserve a class by itself at all. You could instead put the borrow method in a class called Book that represented the model of your application. Then you call borrow on the book, the book does some logic, and returns a status code to the controller. Or since it's a bit silly to ask a book to borrow itself, have a library model object that handles a bunch of book objects, and put the borrow method in the library class. That's how I do MVC anyways.

Re: Are we doing MVC wrong?

#4
It's not that the MVC is wrong, it is that the model is not being built right. Moving to the BorrowABook feature is making a model class.

All too often in my experience I see code that has the model rolled into the controller. Controllers and UI are structurally supported better in frameworks. We get lazy and put model code into controllers. It is the way we make spaghetti code today.

Re: Are we doing MVC wrong?

#5
The controller is always the ugly part, because it's the piece that's responsible for interfacing between transaction-specific logic and your general backend interface. The article is right that it's easy to put too much business logic in the controller, but fails to recognize that "MVC" isn't supposed to be your whole application - just the UI side. The functionality of this BorrowABook class doesn't belong in the UI layer at all.

Re: Are we doing MVC wrong?

#6
post #2

MVC is not a dogma, it is a no-brainer instruction to make 90% of programming fruits less miserable. I usually end up with something like Views-Composers-Handlers-Routes-Libs etc. And this can vary from project to project.

I agree. There's a lot of sentiment around, "the right way to do something". I somewhat blame rails for the explosion of opinions, but maybe it's just developer nature.

The right way is the way that works for you and your business requirements.

Re: Are we doing MVC wrong?

#7
This is similar (or more or less the same) idea that has been advocated by Uncle Bob and others. Here's my comment on the experiences we have had with this approach: https://news.ycombinator.com/item?id=6470693 (the topic was about running tests quickly, and the approach, as mentioned also in the article, decouples the business logic from frameworks - allowing testing without firing up web server, database, etc.).

I agree that the interactors make rather odd-looking OO classes, but I suppose the imperative nature of most requests to perform some logic make them less objects in that sense. This has the added benefit of seeing what the system does, just by looking the class names in the interactors folder/namespace.

Re: Are we doing MVC wrong?

#8
> Features return a glorified tuple (Feature) that combines an enum value that represents what the outcome was, with a value that represents the result of the operation.

Sounds similar to my understanding of what a monad is. If you have many cases of this, it might simplify the switch statement and improve maintainability.

http://devtalk.net/csharp/chained-null-checks-and-the-maybe-...

http://stackoverflow.com/questions/674855/help-a-c-sharp-dev...

Re: Are we doing MVC wrong?

#9
post #5

The controller is always the ugly part, because it's the piece that's responsible for interfacing between transaction-specific logic and your general backend interface. The article is right that it's easy to put too much business logic in the controller, but fails to recognize that "MVC" isn't supposed to be your whole application - just the UI side. The functionality of this BorrowABook class doesn't belong in the U…

MVC is something I've never really been able to wrap my head around. I wonder if this is why... All of the guides/articles that I've read on the subject have acted as if MVC was how the entire application was handled.

Could you recommend any references for back-end patterns?

Post reply on HN