The classic stategy for application development is Model View Controller (MVC). In the original MVC pattern, the Model retains the state of the application. The View renders the Model and acquires input. The Controller accepts input from the View, updates the Model, and selects the next View. The selected View renders the updated Model, closing the loop.
In the enterprise version of MVC (aka MVC2 or Model 2), the View acquires input and passes it to the Controller, initiating a request. The Controller uses the input to update the Model, obtains the current Model state as output, and selects the next View. The View renders the output, completing the request.
Like Descartes, let's start with a first principle. The principle may be simplistic, but that's the point.
Now we can ask ourselves: How do we get there from here?
The first steps are to accept input from the client and verify that the input we need is provided.
If input is missing, an application should fail gracefully and signal that there is an error condition.
Most often, input arrives as text. The input may be coming from a command line program, or a web service, or a UI widget, but most often it arrives as text.
Text is universal, but, internally, most applications need to use date and numeric types too. We need to accept text but convert it to whatever internal representation we need to get the job done.
Once we have the input we need, in a datatype we can use, the application can go about creating output. It's time for the rubber to meet the road.
Clients often expect output values to be rendered in certain ways. Monetary values may need a currency sign. Dates might need to be in long or short formats. A string of digits, like a social security number, may need hyphens inserted here and there.
The output values are returned to the client, and on the presentation layer, a client will continue to work with the output, turning it into a web page – or a PDF or a graphic display. A client might then acquire new input, and the process would start anew.
So far, the five tasks we outlined
describe most of the things that a MVC2 Controller is expected do. An application needs to do many more things, but those tasks can be handled by a presentation layer or a persistence layer. For example, a presentation layer dispatcher could select the next View. Data access objects might interact with a database management system.
But, to get there from here, we need a controller to validate input, tender messages, convert data, process logic, and format output.
If we designed an application controller to do these five core tasks, what would it look like?
Expressed as a workflow, we must
If any errors are detected, we must report the errors to client, without servicing the request.
To complete the workflow, we will need
If input is both malformed and required, we should report both
So that the client knows that the input cannot be omitted.
Given the requirements of our workflow, the controller must provide
(To be continued)