Arquitectura: El Domo de Roma.

En esta ocacion en el podcast de Rock Developer Cesar Reyes y Iaax Page nos hablan sobre el patron de arquitectura Model View Controller. Y como este nos ayuda a desarrollar mejor.

Vinculos del podcast

• Model View Controller de acuerdo a la wikipedia (Ingles)
• Symfony PHP
• Ruby on Rails
• Groovy and Grails
• Asp.net MVC

Este es el episodio Numero 9 del podcast. Estamos trabajando para agregar un mejor feed que les permita descargar los episodios desde el iTunes. Un mejor plugin para el reproductor de MP3 y algunas otras cosas interesantes.

Queremos convertir a RockDeveloper en una mejor comunidad.

Muchas Gracias por su apoyo y no se olviden de hacer click en el boton retweet, en la esquina superior derecha de este post.

Saludos cordiales,

Iaax Page y Cesar Reyes

A veces necesitamos ejecutar una tarea que lleva un tiempo considerable y que el usuario no necesariamente necesita ser informado en el momento, por ejemplo el envío de un correo de notificación (en algunos casos), el hacer un proceso x que lleva tiempo, etc…

La clase TaskExecutor de spring abstrae la de java.concurrent.Executor de manera tal que es mucho mas facil con spring, SimpleAsyncTaskExecutor (asincrono), SyncTaskExecutor (sincrono), SimpleThreadPoolTaskExecutor y otros mas.

Pongo un ejemplo del uso del SimpleAsyncTaskExecutor

private TaskExecutor taskExecutor;

public void setTaskExecutor(TaskExecutor taskExecutor) {
    this.taskExecutor = taskExecutor;
}

taskExecutor.execute(new Runnable(){
    public void run() {
        ...
    }
});

Aquí mostramos la configuración de nuestra clase usando un TaskExecutor en spring.

<bean id="taskExecutor" class="org.springframework.core.task.SimpleAsyncTaskExecutor"/>

<bean id="myBean" class="org.myproject.MyBean">
    <property name="taskExecutor" ref="taskExecutor"/>
</bean>

Cuando usamos hibernate y tenemos relaciones “lazy” en nuestros objetos que son traidos con hibernate, esto nos puede traer problemas al usar simplemente el TaskExecutor, tenemos que hacer una especia de OpenSessionInThread para poder tener la session abierta y que se reutilice esa session a lo largo del codigo ejecutado.

Pongo un ejemplo de como seria esa implementación. El código es similar a la implementación del OpenSessionInViewFilter de spring.

public abstract class OpenSessionInThreadTask implements Runnable{

    private ApplicationContext ctx;

    public OpenSessionInThreadTask(ApplicationContext ctx) {
        this.ctx = ctx;
    }

    protected abstract void runInternal();

    public final void run(){
        SessionFactory sessionFactory = lookupSessionFactory();
        boolean participate = false;

        // single session mode
        if (TransactionSynchronizationManager.hasResource(sessionFactory)) {
            // Do not modify the Session: just set the participate flag.
            participate = true;
        }
        else {
            Session session = getSession(sessionFactory);
            TransactionSynchronizationManager.bindResource(sessionFactory, new SessionHolder(session));
        }

        try{
            runInternal();
        }

        finally {
            if (!participate) {
                // single session mode
                SessionHolder sessionHolder = (SessionHolder) TransactionSynchronizationManager.unbindResource(sessionFactory);
                closeSession(sessionHolder.getSession(), sessionFactory);
            }
        }
    }

    protected SessionFactory lookupSessionFactory() {
        return ctx.getBean("sessionFactory", SessionFactory.class);
    }

    protected Session getSession(SessionFactory sessionFactory) throws DataAccessResourceFailureException {
        Session session = SessionFactoryUtils.getSession(sessionFactory, true);
        FlushMode flushMode = FlushMode.MANUAL;
        if (flushMode != null) {
            session.setFlushMode(flushMode);
        }
        return session;
    }

    protected void closeSession(Session session, SessionFactory sessionFactory) {
        SessionFactoryUtils.closeSession(session);
    }

}

Y por ultimo el uso de la clase OpenSessionInThreadTask, de hecho esta clase ya se encuentra en forza.

taskExecutor.execute(new OpenSessionInThreadTask(ctx){
    public void runInternal() {
        ....
    }
});

Bueno espero que haya sido de su ayuda, no olviden dejar en los comentarios cualquier duda o aporte.

El fin de semana estuve haciendo unas pruebas para ver que tecnología usare para un nuevo proyecto, sin alejarme mucho de lo que ya manejo habitualmente que es: spring, hibernate, forza.

Decidí probar un poco con gorm (Grails Object Relational Mapping) unos de los principales componentes de grails, groovy, el lenguaje que usa grails y spring mvc. Por que no hacer toda la aplicación en grails? pues la idea es aumentar la productividad poco a poco, teniendo el mayor control posible sobre la aplicación, a que me refiero?, bueno, ya usando hibernate a veces hay cosas que parecen magia, pero a veces la magia falla, entonces tienes que leer, analizar, debugear y entender un poco el como esta hecha esa magia, asi que empezamos poco a poco a entender la magia de grails.

Empece por ver la aplicación de ejemplo que viene cuando bajas grails, samples/petstore-mvc, y se ve muy sencillo, se simplifica mucho el acceso a datos, algo que no debería ser la gran ciencia. La aplicación viene por default configurada para hacer uso de una base de datos en memoria, entonces la configuro para que apunte a un servidor postgresql local, y para mi sorpresa deja de funcionar, raro, no ejecuta los inserts/updates pero si los selects, bueno para no hacerla larga, resulta ser que es el manejo de transacciones.

Que sigue?,  sustituyo gorm por el EntityManager de forza, el cual es un “Dao” genérico para simplificar el acceso a datos, junto con otras utilerias. Esto porque tengo ya varios años usando forza, y dado que vamos poco a poco con la nueva tecnologia, dejaremos a gorm para despues.

Groovy? me pareció muy productivo, bastante simple, puedes usar clases de java en groovy y viceversa, de esa manera puedes ir tomando poco a poco lo que te sirve mas de groovy.

Entonces la arquitectura de la aplicacion queda: Capa de acceso a datos con forza/hibernate con clases en groovy, capa de servicios en groovy, controllers en groovy con spring mvc, y jsp para las vistas.

En otro post esta semana voy a detallar la arquitectura de la aplicación y mostrar algunos ejemplos en codigo.

Espero sus comentarios y experiencias, saludos…