Ben Nadel's recent post on MVC and Application Architecture stirred up quite a few comments! It also sparked tons of thoughts for me about my own journey with application architecture.
Years ago, when someone asked me to describe the architecture of a particular application, I remember saying in a chipper tone, "Why, it's using MVC!" But I've learned a lot since then, and I want to share some of my thoughts on how MVC fits into the greater picture of Application Architecture.
What is Application Architecture?
When I ask about the architecture of an application, I'm interested in the major components of the system, and the interactions between them. In a way, it's like an object model but on a macro scale -- I want to know how the big pieces of the application relate to each other. From there, I might be interested in drilling into a particular component and understanding its internal design.
In the world of Web development, I've most frequently seen a multilayer architecture that looks a little something like this:
The term "layer" here is a tad ambiguous, intentionally. The layers might be separated by physical machines, by virtual machines, by process boundaries within the same machine, or simply by packaging within the same process. But in any case, we're drawing a line between them, indicating that those are the core concerns that we want to separate.
What is MVC?
It's tempting to think that these three layers somehow correspond to the three letters of MVC. At best, we could try to make a case for something like this:
Architecture Layer | MVC Component |
---|---|
Presentation | View |
Business | Model / Controller |
Data Access | Model |
Here was my previous line of thinking: "Well, let's see… the word 'view' sounds kind of like 'presentation', so that seems logical enough. And the model is the business model, right? And there's the controller that, eh… kind of goes in with business. And data access… I guess pertains to the model stuff, so I'll put it with that..."
I don't know about you, but whenever I mutter that much, it usually means I'm looking at something the wrong way. And there is indeed something wrong -- I was trying to cram my understanding of MVC into my understanding of Layered Architecture. But in fact, MVC isn't meant to be an Application Architecture pattern at all. It's meant to be a Presentation pattern.
Here's an example of what might go in each layer:
Architecture Layer | Contents |
---|---|
Presentation | MVC |
Business | Services / Domain Objects |
Data Access | Gateways / DAOs |
What is the Model in MVC?
It's important to note that the Model in MVC is not your Service Layer or the Domain Objects. It's your View State.
Yes, if you've got an app that's simple enough, your Business Layer will likely run within the same process as your Presentation Layer. In that case, yes, you could choose to put the Domain Objects into your View State for simplicity. But don't confuse MVC's Model with the Domain Objects -- MVC's Model is View State, and you just happened to put the Domain Objects in it.
MVC and Business Layer
And now I'd like to throw one more monkey wrench into things with a rather daring statement: MVC is not exclusive to the Presentation Layer.
Let's say you're working on an enterprise application that involves a Business Layer that includes a series of services that respond over HTTP. The Business Layer could have multiple clients out there -- one accepts an XML response, one accepts a JSON response, and one accepts flat CSV file.
In this case, your services in the Business Layer could also make excellent use of MVC! Each of those response formats is essentially a View of the Model, and the HTTP endpoint is the Controller. So MVC isn't just for User Interfaces -- it can be properly applied to Application Programming Interfaces!
Other Resources
I hope that helps to clarify a few things that took me a long time to understand! If you're interested, see my book reviews page for some superb books on the subject. They brought me a long ways in my ongoing quest to understand application architecture!
No comments:
Post a Comment