Model-View separation

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Model-View separation

OmegaKV
As idiotic as Model-View separation is as commonly done, it has its roots in a sane idea. The sane idea is this: A GUI has a lot of dependencies, so it is usually a good idea to keep the functional part of the code separate from the GUI part of the code. I will call this the Library-GUI separation. For example, if you want to write graphical program for configuring an serial device, it may be a good idea to develop a non-GUI library that sends commands to the device, and then develop a GUI that calls the library, and maintain separation between the two. This way if you find yourself in a situation where you can't get the GUI dependencies working, you can at least still configure the device using the library. Also, if at some point you decide to also develop a web interface to configure the device, you can reuse the library, so that you don't have to program the sending of commands again.

What makes Model-View separation as it is commonly practiced retarded is that they want a second separation within the GUI. For example they want any dynamic text that is displayed stored in a "Model" class that is separate from the layout. What is the point of this? There is no point. It is just a tool of sophistry. It is just a way for evil programmer scum to make ignorant management think that the good and sane programmer is failing to do what I described in the previous paragraph.
Reply | Threaded
Open this post in threaded view
|

Re: Model-View separation

fschmidt
Administrator
This is really an instance of the general issue of modularity.  Meaningful modules should have a separate codebase.  Modularity within a codebase is pointless and just adds complexity.