My Thoughts on Model-View-Controller, Object-Oriented Programming, and Other Architectural Patterns
Ben Nadel has been sharing his experience on attempting to learn how to apply object-oriented programming (OOP) to his ColdFusion development. I've been reading his posts with enthusiasm and sometimes the comments at the end of the articles take off into totally different tangents. However, all of this has me (and several others I'm sure) thinking and asking some questions about OOP along the way. For one thing, is it feasible to encapsulate all of an application's business logic into a single layer? Sounds a little like the search for the Holy Grail to me. Don't get me wrong, I think striving to separate processes from a user interface is/should be good coding practice. However, when does the quest for keeping business logic separated become overkill? Are there times when it is acceptable to mix my processing with my user interface? What is encapsulation, modularity, polymorphism, and inheritance anyway?
I believe that using OOP is an excellent method to maintain software quality. I fully embrace and continue to work towards achieving re-usability in my programming. Breaking my applications up into discrete units of programming logic makes complete sense to me. However, trying to figure out the best way to approach my projects can often be difficult. (Especially if you're not working with any use cases or functional requirements.)
Some very experienced programmers (much smarter than I) somewhere at some point in time have already applied their very big brains on how to better approach software engineering. Elegant conceptualizations of architectural patterns continue to be developed and poured over by all sorts of web developers and the like inspiring an ever-evolving pool of resources such as a variety of ColdFusion frameworks to choose from.
Frameworks, ORM's (object-relational mapping), MVC (model-view-controller), CRUD (Create, read, update and delete), SOA (Service-oriented architecture) ... oh my gosh, make my head spin faster and faster please! I know what you're thinking. "Should I fully understand all of this before I write another line of code?" Well, no. Should you consider learning some of it at some point in the near future. Well, sure. Why? Well, aren't you on the quest for the Holy Grail too? (Answer yes, please.)
Talk about MVC seems to be everywhere these days. According to Wikipedia, the MVC is one of several architectural patterns used in software engineering. Did you know the MVC pattern was first described way back in 1979? (Cue Smashing Pumpkins song "1979".) Obviously, issues facing us today have been around for quite some time, eh? The cool thing is, there have been, and most likely will always be, an ever-present issue to contend with as it pertains to architecting web applications and other software development projects ... "What's the Best Way to Do This?" As elusive as this may seem, understanding different architectural patterns, frameworks, and so forth can help guide us, as software engineers, toward answering this question.
I recently read an interesting article titled "Comment On The Mythical Business Layer" that threw out a few thoughts on some of this subject matter. Weather or not you agree with the author's perspective, they do seem to bring up some interesting notions. The author argues:
Thinking of an application as existing over three separable layers — persistence, business, and presentation — encourages development towards that goal.
As demonstrated, it's completely infeasible to encapsulate an application's business logic into a single layer. It's also logically impossible.
By the time a developer creates the perfect persistence layer — something that takes in any type of data, tucks it away somewhere, and provides an easy mechanism to retrieve it — he has created a separate infrastructure application. Recreated, actually. The operating system's file system already does exactly that.
By the time a developer creates the perfect presentation layer — something that takes in any type of data and displays it in a flexible manner — he too has recreated an infrastructure application. ASP/PHP/etc with HTML already does a fantastic job of implementing that goal.
The author then suggests:
It's absolutely critical, however, to not 'think' of these layers as persistence, business, and presentation. Database, processing, and user interface are much more appropriate terms.
There are also some very good comments at the end of the article too. However, due to time constraints, you'll just have to read them for yourself.
I'm (always) learning that just because I can make something to be "re-usable" doesn't necessarily make it "better." Those re-usable objects, more often than not, will need to be modified in some way, shape or form, depending on the project. Building a one-size-fits-all application rarely works. There's always someone ready with a suggestion or request for customized modifications to my programs. I'm not against making alterations and such, and see value in using the Agile Software Development methodology where needed. However, I'm not on the Cowboy coding train either.
So where am I on my journey through my thoughts on MVC, OOP and such? Well, I'm still at the beginning actually. So for now, I'm still thinking about it, which I suppose is better than the opposite. Keep on keepin' on.
