22-06-2006 Raul Vicente
Hace poco he encontrado una noticia que me ha llamado la atención se trata de una peculiaridad que incorpora Spring 2.0 el cacheo de datos declarativo.
Uno de los aspectos más importantes a la hora de realizar un portal grande es minimizar las llamadas remotas ya que el rendimiento global se puede ver afectado gravemente. Hasta ahora se podía utilizar la caché de manera programática pero tenía una serie de problemas:
Un ejemplo de cacheo de objetos podría ser este:
public class CustomerManager {
private CustomerDao customerDao;
private CacheKeyGenerator keyGenerator;public Customer load(long customerId) {
validateCustomerId(customerId);
Customer customer = null;Serializable key = keyGenerator.generateKey(customerId);
NamedCache cache = getCache();
customer = (Customer) cache.get(key);
if (customer == null) {customer = customerDao.load(customerId);
cache.put(key, customer);}
return customer;
}
public void update(Customer customer) {
customerDao.update(customer);
Serializable key = keyGenerator.generateKey(customer.getId());
NamedCache cache = getCache();
cache.remove(key);}
private NamedCache getCache() {
return CacheFactory.getCache(“customerCache”);
}
}
Spring 2.0 trae soporte para varios proveedores de servios de caching como pueden ser EHCache, JBoss Cache, Java Caching System, OSCache, Tangosol Coherence, etc. La novedad que ofrece Sping 2.0 es poder eliminar todo este farragoso código utilizando los servicios de caching de manera declarativa.
Sólo habría que dar de alta los siguientes beans en fichero de configuración de nuestra aplicación quedando el applicationContext.xml de esta manera:
< bean id="customerManager"
class=”org.springmodules.cache.samples.business.CustomerManager” />
< property name="customerDao" ref="customerDao" />
< bean />
< coherence:proxy id="customerDao" refId="customerDaoTarget">
< coherence:caching methodName="load" cacheName="customerCache" />
< coherence:flushing methodName="update" cacheNames="customerCache" />
< /coherence:proxy>
< bean id="customerManager"
class="org.springmodules.cache.samples.business.CustomerManager" />
< /bean>
Con Spring 2.0 la clase CustomerManager quedaría de la siguiente manera:
public class CustomerManager {
private CustomerDao customerDao;
public Customer load(long customerId) {
validateCustomerId(customerId);
return customerDao.load(customerId);}
public void update(Customer customer) {
customerDao.update(customer);
}
}
La diferencia es abismal entre ambos códigos por varias razones:
- Para empezar el código es independiente del proveedor del servicio de caching si lo cambiáramos en el futuro bastaría con modificar el fichero de configuración.
- El módulo de acceso a datos sólo se ocupa de acceder a los datos y nada, es decir, sólo realiza la función para la que fue pensado.
- El código es más legible y se puede mantener mucho más fácil que el anterior.
- El código de cacheo no está desperdigado por todos los módulos una y otra vez.
- Spring se encarga de la coherencia de los datos de caché y de la BD con lo que el programador se libera de esa tarea.
El artículo original se encuentra en esta dirección para los que estéis interesados:
http://dev2dev.bea.com/pub/a/2006/05/declarative-caching.html