So today, I had this interesting conversation with my colleague Tyler about the differences between MVC for web development and MVC for rich client desktop development.
Having come from a Swing/SWT Java background, I find myself often trying to apply desktop Object-Oriented paradigms to web development while working on this new Ruby on Rails project with Tyler.
I like the fact that I am attempting to transfer my desktop OO knowledge to the web instead of scrapping it and beginning from scratch. That is because I see so many developers nowadays that learn programming on the web right away from web technology books, ending up without solid OO knowledge. So, they often follow procedural/structural techniques in development that make code obscure and time-costly to maintain.
I learned from Tyler today that it is not recommended to apply the Model View Presenter variation of MVC in web development using session objects. I suggested that we use a stateful Presenter as a session object that abstracts the View that the client is seeing as an HTML file. However, Tyler discouraged it because while using a Presenter to abstract a View makes separation of concerns cleaner, it ends up storing a lot of stateful data on the server that negatively impacts scalability and performance, which are apparently very important web development non-functional requirements. To save the server from storing stateful data about the View, Tyler recommended embedding data directly in served-up HTML files, either as tag attributes or hidden fields, as long as the data did not represent critical information that needed to remain secure. Such stateful data is later utilized by serving it back up to the server on a subsequent action.
Doing Ruby on Rails development is quite a fun journey for a Java desktop developer as I am getting to toy with Ruby, Rails, AJAX, CSS, and other related technologies. It is quite a challenge for a desktop developer to deal with the constraints of web development, such as bandwidth, scalability, security, and the web UI paradigms.