In connection to Magnus last post I mentioned some thoughts I have had for a long time regarding web applications and OO. Since I started in earnest doing web applications in java I have never felt really comfortable with the "common" design pattern. It kind of felt a lot better when doing Tapestry and Wicket but the unease never reall went away. In this post I'll try to put to words something that is still pretty vague in my mind so don't expect any kind of consistent story.
A common wisdom some years ago was that web applications was built in three tiers. The GUI layer with JSP, struts or some stuff like that. Som sort of controller layer or business logic layer, and finally a data access layer. The lower layers might be EJB or Spring. Whichever framework the layers usually are pretty isolated. Data is passed between them in simple structs. This usually results in a lot of mindless copying of data from one struct named 'somethingTO' into another struct called 'somethingFormBean'.
The GUI handlers, the controllers and the data access code are usually stateless, even if an ORM is used the state they hold are pretty simple. In other words, not a lot of object orientation going on.
The problem I think with this pattern is that it does not lend itself to reuse, it contains a lot of boilerplate copying of data transfer objects with no apparent gain. Sure, the layers are isolated from knowing implementation details of other layers. But any form of encapsulation has this goal so the tierd design pattern isn't unique in this.
One 'reaction' to this is naked objects (http://en.wikipedia.org/wiki/Naked_objects). Where basically the domain model is translated to classes. The business logic lives in the domain classes and operations on domain objects are exposed on the web. This sure sounds like a lot more OO-design applied to the web. I have no real experience working with this kind of framework so I might have everything backwards about them but I think the domain model here are related to business rules. Operating on entities like 'customer', 'books' or what nouns that sound relevant to the domain. I would like to name this the bottom-up approach. Desinging from the data layer upwards to the GUI layer.
The thing I would really like to see is a top-down approach to naked objects, maybe topless objects :-) That is, the domain model is not the nouns used to describe some data in a DB or back-end system. Rather I would suggest that the domain in web applications is request and response. So the basic class is request and response, each request is modelled regarding the input data. That is request and post parameters, session parameters and so on. The response is modelled with regards to the information that is to be published from the web server. I think this is more related to the interaction description on a web site, use cases or something similar. So you start with modelling the information that is to be sent to the server and what is to be retrieved. Similar interactions with respect to dataflow can for example be implemented as related classes.
So, relating it to Magnus post about lifecycles of objects. One could model the request/response as a state machine. The start state is the request coming in to the server. Proceeds through states like validating input, deciding where to go next, run business rules, retreive/update data, format for display, render html and then end. In this way the same state machine (might be the same implementing class) collects information and decides where to go. So a web framework would end up as something that has a repository of state machines that is triggered from the HttpServletRequest.
Yeah, I don't know. Perhaps that would lend itself to more OO practices in implementing web stuff. I guess I have to build it and see :-)
Some completely unrelated notices:
A remainder about writing JDK proxies and handling InvocationTargetException
Check out the fork of HiveMind called Gaderian
So some chain-of-command where each stage gets to refine the request or contribute to the result? Or actually, I guess the chain will be more like a tree when you have components.
ReplyDeleteSoudns like an interesting idea that I'd be glad to read a follow-up on when you've tried it out ;-) One thing that could be fun to explore is the type of the steps in the chain. For instance, a step that validates the arguments will take a request with string parameters and refine it into a request with typed ones. Later stages must be able to express that they expect a request in this state instead. If every step refines the request or response in a way that the others depend on, then the type of the n:th stage sill be one that takes a request and response in the n-1:th state, and the whole chain setup is reproduced in the type of the last stage. Hopefully it will not be that bad. My hunch is that you will get 3-4 different phases, which gives 2-3 types for the stages on the border between phases and 3-4 types for stages within phases.