This post is part of The Software Architecture Chronicles, a series of posts about Software Architecture. In them, I write about what I’ve learned about Software Architecture, how I think of it, and how I use that knowledge. The contents of this post might make more sense if you read the previous posts in this series.
Creating maintainable applications has always been the real long-term challenge of building applications.
Not long ago, I worked for a company whose core business application was a SaaS platform, used by a few thousands of client companies. That crucial application was three years old and had code files with HTML, CSS, business logic and SQL mixed up. Of course, two years after being released, the company decided to rebuild it from scratch. Although these situations still happen, today many of us know these practices are wrong and know how to avoid them.
However, back in the 1970s, mixing responsibilities was the common practice and people were still trying to discover how to do it better. As application complexity grew, making changes to the UI would inevitably imply changes to the business logic as well, increasing the complexity of the changes, the time spent to do those changes and the likelihood of bugs (because there would be more code changed).
MCV came into play to solve those problems, by promoting “separation of concerns” between front-end and back-end.
@hgraca 