Infrastructure, business logic and degrees of expression
At one point I wrote a code-generator that was looking up the table description in an Oracle database, take a look at some configuration files and create a DAO for accessing that table. The DB was accessed thru straight JDBC and not thru an ORM framework. We basically had to generate 2 classes that were supposed to be used by their clients: a POJO that was mapping to the table and could have some business logic methods and an access bean that would implement all the CRUD operations and could also have some business logic.
The solution was to generate 4 files: 2 files for the POJO and 2 files for the access bean. The POJO would have a super-class that was generated all the time by the tool and contained the getters and setters for the POJO and a sub-class that would be generated only the first time and that would extend the super-class. The sub-class would contain business-logic methods. The same things were generated for the access bean: a super-class that implemented the CRUD operations and get generated all the time and a sub-class that would contain business-logic methods and would be generated only the first time. Again, the sub-class would extend the super-class.
I was thinking about it and I came to the conclusion that what I basically did was to separate infrastructure (getters and setters, CRUD operations) from business logic. The infrastructure was implemented in the super-class and the sub-class was concerned only with business logic. The infrastructure could be generated and re-generated from various descriptors while the business logic could not be generated because it was too fine grained for it to be expressed in descriptors.
I think this is a good separation of concerns and one that would be beneficial to development if it is thought out carefully. I am not too crazy about code generators and in the above case we used it because we didn’t have a ORM framework at the time (this was pre-Hibernate and all that), but this separation is important and could be used beyond code-generation. You could use it to determine what components of an application are generic enough so that they can be either generated by a code generator or handled by a framework targeted exclusively at managing that component of the application. The rest of your application would be behavior so fine grained that it cannot be expressed in config files and is better expressed in business logic beans.
The difference between infrastructure and business logic is basically a difference in the degree of expression of various components in the application. Infrastructure has a very low degree of expression: it can be described in config files. Business logic, on the other side has a very high degree of expression, it needs to be coded.
To give an example for the above ideas: let’s say that you have a client that connects to a web-service. One way to implement this would be to use a code-generator (such as the one supplied with Apache Axis) and generate the stubs that connect to this web-service. Well, it is possible that the web-service would change in the future. In order to adapt to this change easily you could generate the web-service connection classes in a super-class (that would implement the infrastructure) and create a sub-class that would be called from your application (that would implement the business-logic). Changes in the web-service would result in changes in the super-class (which is not used by your application) and would not require big refactoring on your application.
Once again, I am not a big fan of code-generation. I was using the above as an example of the benefits of separating infrastructure from business-logic. You could use this separation for implementing generic behavior in a Template for example, but it is important to notice this separation and enforce it.
