Sunday, 8 August 2010

Software Architecture

Having used the Cairngorm framework with ActionScript, I am beginning to question the overhead that they introduce. In preparation for assisting with a course that taught Spring and Hibernate, I implemented a Spring example and concluded that it also adds overhead in terms of maintenance and operations.

A common feature with model-view-controller frameworks is the use of a controller to distribute to commands or actions. The coding examples for Java often use a common action listener that then has to determine who should process the request. In both Flex / ActionScript and Java, it is possible to write the event to call the handler or action listener for that event, that is to rely on the controller or dispatcher in the interface code. The problem is that this is seen as hard wiring so framework designers look for a way to disconnect events from actions. In the case of controllers, this is seems to be done by introducing another dispatch mechanism instead of finding a way to inject into the view the dependencies. With Spring, it is injecting URLs or servlets into web pages. Why is there a desire to inject a single entry point controller that then has to redispatch the request through some decision process? The dispatch mechanism, already exists and we should make use of it.

A second issue is what I regard as configuration complexity. With Cairngorm when a command was added multiple places had to be updated. Looking at Spring and Hibernate, there seems to be the class files and at least one XML file. Actually with Hibernate, there were other changes in the Java code to tell Hibernate to use the class as well as the logic for doing the update. The Spring examples also seem to have these multiple place updates. The use of annotations can reduce this further. In the case of Hibernate, the annotations in the class file may be all that is required, Spring is also moving to annotations but I suspect that for dependency injection, there still needs to be some configuration file.

The frameworks trade off hard links for greater configuration maintenance. If the configuration can't be verified other than by executing the code then the gains are questionable. The programmer loses some of the syntactic verification.

Native objects uses an approach that doesn't build view objects or data access objects. The native objects framework uses the domain objects to build the user interface and the data access. Annotations are used to provide additional information to the native objects framework but the programmer focuses on domain issues rather than the surrounding technical issues. The interface or views have to match the standard views of the framework and this may make it unsuitable for some applications where a more graphical user interface is required.

If as in the case of native objects, there is a gain in terms of being easier to configure to achieve the same results then there are advantages to using a framework. However, the application needs to be able to fit the assumptions of the framework. I am not convinced that a framework necessarily leads to better reuse but it could lead to easier ability to replace objects with alternative solutions.

The final area where a framework might win is with the idea of liberated objects. CLISP has the function as the core unit. However, CLISP objects and functions can't exist outside the CLISP environment. Exploiting objects to enable wider integration of objects into other applications possibly even defining new relationships seems to be still beyond the scope of these frameworks.

No comments: