El entorno de produccion es aquel siniestro lugar al cual estamos sentenciados y nos dirigimos cada vez.
Diseñar una arquitectura que nos permita cierta flexibilidad y la vez rigidez en su propia base ayudara a que nuestra implementacion y posterior deployment este bajo nuestro control.
Si algo escapa de nuestro control, todo sera un dolor de cabeza.
Una de estas arquitecturas es el desarrollo sobre Tres Capas, muy conocida por cierto, excesivamente utilizada y pesimamente implementada, la mayoria de las veces.
En el diseño de una arquitectura, debes concebir que la capa inferior facilite las tareas de la capa superior, y que esta la utilize de manera simple y natural.
Aquella es la idea, su razon de ser.
NO debe exisitr redundancia de operaciones entre una capa y la otra. De lo contrario, NO tendria mayor valor NI significado su existencia.
Por ejemplo, en el clasico y trivial ejercicio, donse se requiere sumar dos numeros enteros ubicados sobre un WebForm, en el cual se debe ingresar los datos sobre un par de controles TextBox y un boton que ejecute la operacion para que se muestre el resultado en otro TextBox establecido en modo readonly, muy probablemente te encuentres con un diseño de tres capas, similar a este:
private void Sumar_Click( Object sender, EventArgs e )
{
BLSumar o = new BLSumar();
this.c.Text = BLSumar.Calculate( this.a.Text, this.b.Text );
}
De esta manenra, la clase BLSumar, donde BL nos quiere decir Business Layer, tendra, muy probablemente, una implementacion como esta:
public class BLSumar()
{
public Int32 Calculate( Int32 a, Int32 b )
{
DLSumar o = new DLSumar();
return o.Insert( a, b );
}
}
Del mismo modo, la clase DLSumar, donde DL nos quiere decir Data Layer, ajustara su implementacion en algo similar a esto:
public class DLSumar()
{
public Int32 Insert( Int32 a, Int32 b )
{
Store procedure = new Store( "SP_SumarInsert" );
procedure.AddInParameter( a );
procedure.AddInParameter( b );
procedure.AddOutputParameter( "c" );
Helper.ExecuteNonQuery( procedure );
return procedure.Parameters[ "c" ].Value;
}
}
Asumiendo, para los efectos de la explicacion, que existe una Tabla en la Database con tres campos, donde los dos primeros seria los sumandos de la operacion y el tercero un campo calculado que obtiene la suma aritmetica de los dos primeros, entonces continuamos :)
En este supuesto escenario, ¿cual seria la razon de ser del Business Layer que funciona de mero wrapper del Data Layer?
Recuerda que aun falta la implementacion del Store Procedure que es llamado desde la clase DLSumar, que en teoria debe realizar un simple INSERT sobre la tabla Suma.
¿Tantas clases y un store procedure para realizar una operacion tan simple?
Por Dios! Nunca fue tan laborioso realizar una operacion contra la Database :)
Definitivamente, algo anda mal. Ten la plena seguridad que NO estamos haciendo las cosas bien.
La solucion poco decorosa de una implementacion sobre Tres capas, de esta manera, solo provoca que se gasten lineas de codigo entre una capa y otra, sin mayor valor agregado para los efectos del resultado final.
Aplicando el mismo criterio para la construccion de tus clases, en la vida real, donde te has de encontrar con un mayor numero de tablas y un abrumador numero de campos por cada tabla, entonces nos damos cuenta que nuestra solucion es una verdadera porqueria :)
La correcta solucion pasa por darle a la implementacion de cada capa un valor agregado que facilite la vida de la capa superior. NO redundar con la misma operacion, en contextos distintos.
Una implementacion de esta manera, promueve el COPY & PASTE.
Si ello sucede en la construccion de tu producto de software, estate seguro que nuestro desarrollo camina a piñon fijo hacia una pesima escalabilidad con el codigo disgregado por everywhere.
Dolorosamente sostenible en el tiempo, aburridamente mantenible y vergonzosamente presentable :)
No comments:
Post a Comment