A co-worker has been using "Protocol State Machines" as a way to describe RESTful architectures a lot lately so I started Googling around a bit. This turned into a few days worth of reading arbitrary articles. I am always surprised by how much of this discussion I missed over the past few years.
It all started with CRUD is bad for REST over at SOA Zone. Interestingly enough, this quoted an post that I read a few years ago by Tim Ewald. As an aside, Tim is the aforementioned "co-worker". Another interesting note is that I scrawled something similar on an office whiteboard a little while back "REST is not CRUD" based on a former weekend spent reading similar topics. But I digress.
Tim's post lead to a response entitled "My Bow-Legged Master" by Bill de hÓra that is equally well written. Next I went on to a hilarious linked post by Ryan Tomayko about scalability and LAMP. Ryan posted about the evils of multi-threaded programming in an earlier entry named Unicorn is UNIX which I liked very much. I'll get back to this in a second. Somewhere in the web of documents, I came across "RETRO: A (hopefully) RESTful Transaction Model" which is a lot more than I feel like digesting on a Saturday morning with my coffee. It looks like a very interesting post from the middle of last year by Alexandros Marinos. Save it as a bookmark and come back to it I guess...
The RETRO discussion blog contained an interesting link in the blog list that caught my eye. It was a presentation from PyCon 2010 entitled "Threading is not a Model". If you have some time to burn, check out the various talks from PyCon. They are interesting even if you are not a Python person. You should definitely listen to Dude, Where's my Database?. This is not directly related to REST. Threading and REST an inextricably linked (more later) but this presentation did not directly hit on it. However, it is a really clear description of why threading is not really such a good idea all of the time. Back to that RESTful thing now...
For some reason the post from Ryan evoked my memory of his Unicorn post. When I read this a few months back, it set off a storm in my head. This reminded me of a similar article that I read years back named "The Problem with Threads". This is all starting to come together for me.
RESTful thinking is all about Shared Nothing architectures and stateless clients. The complexity of multi-threaded programming is just another instance of the same shared state problem that RESTful thinking is trying to dissuade us away from. Many people see relational databases as a similar exposition of the shared data problem - I believe that this is where a lot of the NoSQL stuff is coming from. Anyway... I'm starting to see a lot of commonality between RESTful/Shared-nothing architectures and the multiprocess programming instead of multithreaded programming. That's more than enough for one morning of reading.
27 February 2010
03 January 2010
What happened to MVC?
So I have been thinking about this a lot lately. Mainly because of a number of MVC related posts on Stack Overflow and also because it has come up in conversations at work. I keep coming back to the same thought over and over again.
The View is responsible for the presenting the Model or a portion of it. If this is a user interface that we are talking about, then there are probably multiple views. The key point is that each view handles the details associated with it's presentation. The view keeps track of whatever presentation state (e.g., selected row) is needed. Really complex views may require a surrogate model or a model of their own but this is completely distinct from the domain model.
The Model represents the objects in the system in an abstraction that is appropriate for the domain. The model is the persistent part of the system - not necessarily the only persistent part but definitely the most important for the MVC model.
Now there are some interesting relationships that MVC describes that are very important to understanding the architecture as a whole. These are captured as the little directed arrows between the components. The direction of each arrow indicates information flow. The interface is composed of the output from one or more views. The user interacts with the interface by either:
The second case is more interesting. When the interface needs to actually manipulate the underlying model, it does so by sending a message to the controller. The controller manipulates the domain objects defined in the model. In a perfect system, the changes are reflected immediately in the views. How this happens is probably going to be the topic of another rant or... umm... post. The MVC pattern does not prescribe how this might happen; it just assumes that changes in the model are reflected in the interface.
Starting from the top, the Presentation tier is responsible for the user-interface as a whole. All interaction with the user passes through this layer first. This is where the widgets, layout, and formatting are implemented. It does this in terms of business objects exposed by the business logic layer.
The Business Logic tier implements the guts of the application. It defines the objects presented to the presentation along with the actions that are available on each object. The relationships between objects is also defined and enforced in this layer.
The Persistence layer provides a low-level data abstraction with guaranteed persistence. In most cases, this layer isn't more than a database of the business objects. This layer might (and usually does) employ some form of Object-Relational Mapper to fulfill its requirements.
All interactions flow through the stack from the top down. The nice thing about this architecture is that it allows for the same business logic to be used with multiple presentation layers so supporting different views is easy - add a new presentation layer. Upgrades and versioning is simple as well since each layer depends on the adjacent layers only; this becomes even more useful when the number of tiers is increased.
Differences and Common Thoughts
Now to the heart of this little post. The MVC and n-Tier architectural styles are distinctly different beasties. I think that everyone can agree on that or, at least, I would hope so. This is where I have been quite surprised recently. Here are a few quotes from Stack Overflow that piqued my interest:
I don't mean to pick on these authors specifically (I included links so you can see the rest of the post). Both of these approaches sound like the canonical definition of 3-tier architectures. Maybe I missed something over the years, but there is a distinct difference between the architectural styles that has gotten lost.
Maybe the source of this is that a good number of frameworks also seem to misunderstand the basic paradigm of model-view-controller. Here's an example from CodeIgniter (a popular PHP framework that touts an MVC architecture):
Wow... controllers and views without a model. Now that is an interesting interpretation since the Model is the core of MVC. Remember that the View is a view of the model and the Controller manipulates the model. What good is a controller and view without a model?
Maybe what we are seeing is that MVC is being redefined to look a lot more like 3-tier or are we seeing a wholly new architectural style?
Surprisingly enough, Microsoft seems to be heading in an interesting direction with the Model-View-ViewModel pattern. Yes, the controller is missing in the acronym. John Gossman commented on this in his original blog entry on MVVM. The interesting thing is that this pattern extends conventional MVC with a presentation-side model, hence the ViewModel part. Basically, when the presentation layer is complex enough to warrant it's own state, introduce a model for the presentation layer independent of the domain object model. Now that is actually an interesting advance.
Why do so many people have such difficulty distinguishing between MVC and n-Tier architectures?It seems pretty simple to me. Let's define them as I see them before continuing. Maybe my understanding is just skewed so you won't have to read too far if it is.
Model-View-Controller
Figure 1 is a pretty standard diagram of an MVC architecture off there on the right hand side. We have the User of the application represented on the left-hand side; most diagrams seem to leave out the user for some god-awful reason. The Controller is up on top. It is responsible for responding to actions invoked by somebody - could be the User or the View for that matter. The controller is the primary manipulator of the model. |  Figure 1 |
The View is responsible for the presenting the Model or a portion of it. If this is a user interface that we are talking about, then there are probably multiple views. The key point is that each view handles the details associated with it's presentation. The view keeps track of whatever presentation state (e.g., selected row) is needed. Really complex views may require a surrogate model or a model of their own but this is completely distinct from the domain model.
The Model represents the objects in the system in an abstraction that is appropriate for the domain. The model is the persistent part of the system - not necessarily the only persistent part but definitely the most important for the MVC model.
Now there are some interesting relationships that MVC describes that are very important to understanding the architecture as a whole. These are captured as the little directed arrows between the components. The direction of each arrow indicates information flow. The interface is composed of the output from one or more views. The user interacts with the interface by either:
- manipulating one of the views or
- sending action messages to the controller
The second case is more interesting. When the interface needs to actually manipulate the underlying model, it does so by sending a message to the controller. The controller manipulates the domain objects defined in the model. In a perfect system, the changes are reflected immediately in the views. How this happens is probably going to be the topic of another rant or... umm... post. The MVC pattern does not prescribe how this might happen; it just assumes that changes in the model are reflected in the interface.
n-Tier Architectures
 Figure 2 | n-Tier architectures are defined by n layers arranged as a stack. Each tier is responsible for implementing a different portion of the application. The classic web architecture is the 3-tier architecture depicted in Figure 2 to the left. This architecture arose to solve similar problems. The goal was to separate data representation from presentation and business logic. Of course, the common goals of shared representation, shared code, separation of concerns, clean abstraction, etc. etc. etc. were also key in it's evolution. |
Starting from the top, the Presentation tier is responsible for the user-interface as a whole. All interaction with the user passes through this layer first. This is where the widgets, layout, and formatting are implemented. It does this in terms of business objects exposed by the business logic layer.
The Business Logic tier implements the guts of the application. It defines the objects presented to the presentation along with the actions that are available on each object. The relationships between objects is also defined and enforced in this layer.
The Persistence layer provides a low-level data abstraction with guaranteed persistence. In most cases, this layer isn't more than a database of the business objects. This layer might (and usually does) employ some form of Object-Relational Mapper to fulfill its requirements.
All interactions flow through the stack from the top down. The nice thing about this architecture is that it allows for the same business logic to be used with multiple presentation layers so supporting different views is easy - add a new presentation layer. Upgrades and versioning is simple as well since each layer depends on the adjacent layers only; this becomes even more useful when the number of tiers is increased.
Differences and Common Thoughts
Now to the heart of this little post. The MVC and n-Tier architectural styles are distinctly different beasties. I think that everyone can agree on that or, at least, I would hope so. This is where I have been quite surprised recently. Here are a few quotes from Stack Overflow that piqued my interest:
I don't mean to pick on these authors specifically (I included links so you can see the rest of the post). Both of these approaches sound like the canonical definition of 3-tier architectures. Maybe I missed something over the years, but there is a distinct difference between the architectural styles that has gotten lost.
Maybe the source of this is that a good number of frameworks also seem to misunderstand the basic paradigm of model-view-controller. Here's an example from CodeIgniter (a popular PHP framework that touts an MVC architecture):
CodeIgniter is based on the Model-View-Controller development pattern. MVC is a software approach that separates application logic from presentation. In practice, it permits your web pages to contain minimal scripting since the presentation is separate from the PHP scripting.
CodeIgniter has a fairly loose approach to MVC since Models are not required. If you don't need the added separation, or find that maintaining models requires more complexity than you want, you can ignore them and build your application minimally using Controllers and Views. CodeIgniter also enables you to incorporate your own existing scripts, or even develop core libraries for the system, enabling you to work in a way that makes the most sense to you. [3]
- The Model represents your data structures. Typically your model classes will contain functions that help you retrieve, insert, and update information in your database.
- The View is the information that is being presented to a user. A View will normally be a web page, but in CodeIgniter, a view can also be a page fragment like a header or footer. It can also be an RSS page, or any other type of "page".
- The Controller serves as an intermediary between the Model, the View, and any other resources needed to process the HTTP request and generate a web page.
CodeIgniter has a fairly loose approach to MVC since Models are not required. If you don't need the added separation, or find that maintaining models requires more complexity than you want, you can ignore them and build your application minimally using Controllers and Views. CodeIgniter also enables you to incorporate your own existing scripts, or even develop core libraries for the system, enabling you to work in a way that makes the most sense to you. [3]
Wow... controllers and views without a model. Now that is an interesting interpretation since the Model is the core of MVC. Remember that the View is a view of the model and the Controller manipulates the model. What good is a controller and view without a model?
Maybe what we are seeing is that MVC is being redefined to look a lot more like 3-tier or are we seeing a wholly new architectural style?
Surprisingly enough, Microsoft seems to be heading in an interesting direction with the Model-View-ViewModel pattern. Yes, the controller is missing in the acronym. John Gossman commented on this in his original blog entry on MVVM. The interesting thing is that this pattern extends conventional MVC with a presentation-side model, hence the ViewModel part. Basically, when the presentation layer is complex enough to warrant it's own state, introduce a model for the presentation layer independent of the domain object model. Now that is actually an interesting advance.
Links of Interest
Subscribe to:
Posts (Atom)