brainmuffin
Apr 28th, 2006, 06:20 AM
Soon I will be involved in redesigning 4 brand sites for a major client of ours. The largest brand site uses ATG's Dynamo 5.1 and will be moving to 7.1. Another uses Spring, Struts and Hibernate under SunOne 6.1, but there is a very good possibility they will move to ATG 7.1 before July of 2007. The other two sites are under iPlanet 6.0, but will be migrated to SunOne 6.1 and Spring/Hibernate (not sure of which MVC package yet, perhaps Spring MVC).
For the Spring site, I am (and will be using on the redesigns) using interface definition in the form actions (and form handlers for ATG) to define the API for the business logic. In the business logic layer, interfaces define the API for the DAO, but concrete objects are passed from layer to layer. This is fine for Hibernate as it maps concrete beans to tables, but ATG does not. It's repository framework uses a dynamic bean and has .getProperty(name) and .setProperty(name, value_object) methods. As I want to minimize recoding when a site moves from SunOne to ATG, I was thinking of using a interface definition between the layers and define a beanfactory that returns implementing objects. In the Spring world, this would return true concrete objects, but under ATG they would just be facade for the RepositoryItem underneath. That way any layer that wanted to say access the first name would always be .getFirstName() and .setFirstName(newFirstName) and not .getProperty("firstName") and .setFirstName("firstName", newFirstName).
How does such a scheme fit into best practices? Is this taking abstraction too far?
For the Spring site, I am (and will be using on the redesigns) using interface definition in the form actions (and form handlers for ATG) to define the API for the business logic. In the business logic layer, interfaces define the API for the DAO, but concrete objects are passed from layer to layer. This is fine for Hibernate as it maps concrete beans to tables, but ATG does not. It's repository framework uses a dynamic bean and has .getProperty(name) and .setProperty(name, value_object) methods. As I want to minimize recoding when a site moves from SunOne to ATG, I was thinking of using a interface definition between the layers and define a beanfactory that returns implementing objects. In the Spring world, this would return true concrete objects, but under ATG they would just be facade for the RepositoryItem underneath. That way any layer that wanted to say access the first name would always be .getFirstName() and .setFirstName(newFirstName) and not .getProperty("firstName") and .setFirstName("firstName", newFirstName).
How does such a scheme fit into best practices? Is this taking abstraction too far?