Is MVC just a meme? As far as I understand, the goal is to make the three components reusable. But I don't see how I could ever reuse a controller with a different model or a different view. It's also most likely going to end up in a giant unmaintainable class with tons of static methods. The model part is pretty much the only part that makes sense to me, you can build some nice reusable objects that encapsulate the data the applications work with.
What's the best way to structure software in a way that you could use the same or almost the same backend for both a desktop and a web application? Redux' concept looks kind of nice and could absolutely be adapted to non-JS software: redux.js.org/introduction/coreconcepts
You should have multiple controllers you spastic. How else are you going to model multiple business tasks?
And honestly you can't see how you might have multiple views?
Chase Taylor
OP, if you're in the front end, chances are the controller is embedded in the view. That's why more and more people are talking about MV* or even MVW (model view whatever). If you are in a backend env. then it is different because your controller will have to extend a base controller that already handles, say, POST/GET data capture, transformation and sanitation, to in the end query the model. It depends on your architecture and if you're more in the frontend or backend.
It has some to do with reusability and a lot about separation of concerns. If you change something about the presentation, the last thing you want is for your business logic to inadvertently change because you tightly coupled your business logic and presentation logic.
Not sure what you're on about with static methods either. It's mostly all instance methods.
To answer your actual question, generally you will have a set of reusable libraries that contain your model classes. You then have a server application and separate applications for each of your clients. Generally (in enterprise applications) clients communicate with the server using a REST API/plain HTTP/gRPC/some other RPC technology.
Thomas Jackson
The thing is that in all these architectures the role of the controler, view and how they comunicate is a fucking mess. MVC is nice in theory, but I still have to see a pure implementation that is not an horrible mess
>it's the best way to structure an application ftfy
Unless you write low level, MVC is the way to address any modern application, be it a RIA or a desktop application. It's flexible, it's easier to test, it's to adjust and/or replace, other people understand the concept as well as it's a design pattern that any serious programmer should know by heart.
Jonathan Gomez
>it's easier to test. This.
Daniel Parker
Apple WebObjects did this correctly eol 2008 But you're right, everything I've seen since mixes VC to the point they're inseparable
Matthew Cooper
This is actually where my problems started. I got both of his books and it definitely changed the way I look at OOP. Now I look at how other people do MVC and it's just dirty. I don't like his approach though, because it's kind of hard to implement an application flow (that's not stateless) this way.
The controller needs to know how to modify the model, which means it's tightly coupled to it. It also needs to know what data to inject into the view. Sure, parts of it can be reused. But then you just keep on adding shit to it to expand it, which makes it unmaintainable.
>The thing is that in all these architectures the role of the controler, view and how they comunicate is a fucking mess. >MVC is nice in theory, but I still have to see a pure implementation that is not an horrible mess Thank you, this is exactly the problem I have.
Kevin Diaz
Learn Symfony and stop bitching
Carson Sanders
>PHP Yeah how about no.
Parker Powell
PHP is pretty great, Jow Forums only hates it because Jow Forums is contrarian.
Nathaniel White
How is that any different?
Adam Butler
Sanitation/verification/validation are shit in PHP though.
Nicholas Bailey
I'm glad I have no idea what I'm doing when I write code.
