(1 item) |
|
(1 item) |
|
(5 items) |
|
(1 item) |
|
(1 item) |
|
(2 items) |
|
(2 items) |
|
(4 items) |
|
(1 item) |
|
(6 items) |
|
(2 items) |
|
(4 items) |
|
(1 item) |
|
(4 items) |
|
(2 items) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(2 items) |
|
(2 items) |
|
(5 items) |
|
(3 items) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(3 items) |
|
(1 item) |
|
(1 item) |
|
(2 items) |
|
(8 items) |
|
(2 items) |
|
(7 items) |
|
(2 items) |
|
(2 items) |
|
(1 item) |
|
(2 items) |
|
(1 item) |
|
(2 items) |
|
(4 items) |
|
(1 item) |
|
(5 items) |
|
(1 item) |
|
(3 items) |
|
(2 items) |
|
(2 items) |
|
(8 items) |
|
(7 items) |
|
(3 items) |
|
(7 items) |
|
(6 items) |
|
(1 item) |
|
(2 items) |
|
(5 items) |
|
(5 items) |
|
(7 items) |
|
(3 items) |
|
(7 items) |
|
(16 items) |
|
(10 items) |
|
(27 items) |
|
(15 items) |
|
(15 items) |
|
(13 items) |
|
(16 items) |
|
(15 items) |
In my previous blog, I attempted to answer Ted's question: "Is an Oracle database a service?" When considering what may or may not be a service, one person's service boundary is another person's implementation detail - it all depends on your point of view. Unfortunately for Ted, this doesn't advance his quest to find a meaningful definition of SO. What use is it if I can decompose one system in two different ways to come up with different answers to the question: "Is this bit here a service?"
Then again, maybe it's not really a problem at all. In fact it's just a specific instance of a more general pattern: the role a particular piece of your system appears to fulfil may change according to the scale at which you are working.
It's not exactly unusual for a particular abstraction to be applicable at more than one scale, and for this to result in apparently inconsistent labels. I think MVC is a prime example of this. Consider a window in an application. The window presents a view onto some information, and supports various interactions that may result in things being done to the data - just the kind of scenario that MVC is useful in. But what exactly is the model? Often there are two answers.
One perfectly valid and rather obvious point of view is that the model is whatever underlying data the form lets me edit. For example, the model might be the collection of documents that make up this blog. In this world view, the form I use to create and edit blog entries is clearly the view, and the logic that handles user actions, and performs the necessary operations on the model looks like the controller.
An equally valid but frequently overlooked alternative point of view is to look at things on a smaller scale. Suppose my editing UI offers smart tag popups, spell checking, and all the other gizmos that make the whole rich client editing experience so much nicer than your basic HTML editing UI. A pop-up smart tag is a thing the user can see and interact with. So isn't it also the kind of thing to which we can apply MVC? There will be some model that defines what is in the smart tag, a view to make it visible, and a controller to work out what to do when the user interacts with the view.
According to the first perspective, the view includes the form and all its internal behaviour - smart tags and the like are an internal detail of the view. But according to the second perspective, this very same body of code is a composite entity with a model, view, and controller.
Both perspectives are valid and useful. Neither is more correct than the other despite the apparent contradiction. The one you choose will depend on the scale at which you are considering the system. I think the same applies to the two points of view that support the idea that the database is both a service in its own right, and an internal implementation detail of some other service.