Foros del Web » Programación para mayores de 30 ;) » .NET »

Paranoia por la arquitectura de tres capas.

Estas en el tema de Paranoia por la arquitectura de tres capas. en el foro de .NET en Foros del Web. Hola a todos, tengo una pequeña duda acerca de la arquitectura de aplicaciones de tres capas, especificamente mi duda esta basada en la capa de ...
  #1 (permalink)  
Antiguo 26/04/2006, 10:28
Rodolfo Israel
Invitado
 
Mensajes: n/a
Puntos:
Pregunta Paranoia por la arquitectura de tres capas.

Hola a todos, tengo una pequeña duda acerca de la arquitectura de aplicaciones de tres capas, especificamente mi duda esta basada en la capa de reglas, veamos, tengo el siguiente escenario, actualmente en mi base de datos tengo una tabla llamada CONTADORES, con la siguientes columnas: DESCRIPCION_CONTADOR (varchar), VALOR_CONTADOR (int), el proposito de la misma es llevar un conteo secuencial de valores para un determinado contador, por ejemplo, DESCRIPCION_CONTADOR = "Total_Clientes", VALOR_CONTADOR = "3", de tal manera que cuando agrego un nuevo cliente el contador aumenta en 1, esa es la regla, cada vez que agrego un registro mi contador debe aumentar en 1, el caso es que en mi capa de datos tengo las funciones necesarios para leer un registro y que llaman al procedimiento almacenado SelectByDescripcionContador con la siguiente definicion:

Código:
CREATE PROCEDURE SelectByDescripcionContador
    @DESCRIPCION_CONTADOR varchar(30),
AS

SELECT
    [DESCRIPCION_CONTADOR],
    [VALOR_CONTADOR],
FROM
    [CONTADORES]
WHERE
    [DESCRIPCION_CONTADOR] = @DESCRIPCION_CONTADOR
pero mi duda especificamente es como hacer mi procedimiento almacenado update, que es el que actualizaria el valor de mi contador, mi duda es si es correcto que implemente esa regla del negocio en mi procedimiento almacenado de la siguiente manera:

Código:
CREATE PROCEDURE ContadorUpdateValor
    @DESCRIPCION_CONTADOR varchar(30),
AS

SELECT
    [VALOR_CONTADOR] = [VALOR_CONTADOR] + 1 --Aquí esta la regla del negocio
FROM
    [CONTADORES]
WHERE
    [DESCRIPCION_CONTADOR] = @DESCRIPCION_CONTADOR
de esta manera solo basta con llamar a este procedimiento desde mi capa de reglas para que el servidor de bases de datos sea el que haga la suma y la actualizacion, o bien seria recomendable hacer mi procedimiento almacenado update de la siguiente manera:

Código:
 CREATE PROCEDURE ContadorUpdateValor
     @DESCRIPCION_CONTADOR varchar(30),
    @NUEVO_VALOR int,
AS
 SELECT
    [VALOR_CONTADOR] = @NUEVO_VALOR --No hay regla del negocio aqui
 FROM
     [CONTADORES]
 WHERE
     [DESCRIPCION_CONTADOR] = @DESCRIPCION_CONTADOR
e implementar esa suma en el codigo fuente de mi capa de reglas del negocio, de tal manera que cuando llame a mi capa de datos para que actualice mi tabla el valor ya este calculado por la regla del negocio.

No se si me explique correctamente, mi duda es que procedimiento almacenado Update usar, ¿implemento esa regla en la capa de reglas o en mi procedimiento almacenado?, quizas desde el punto de vista de la eficiencia sea aconsejable implementar la regla en mi procedimiento almacenado, pero desde el punto de vista de la programacion en tres capas, que es el punto de vista que me interesa, lo correcto sea implementar esa regla en el codigo fuente, En fin si no me explique espero me lo hagan saber, el ejemplo que les puse fue solo ilustrativo, pero en el proyecto que estoy desarrollando actualmente me he enfrentado muchas veces con problemas de diseño de este tipo, quiero saber si he tomado la desicion correcta pues algunos programadores se han quejado.

Saludos y gracias de antemano por sus comentarios .
  #2 (permalink)  
Antiguo 26/04/2006, 11:17
 
Fecha de Ingreso: enero-2006
Mensajes: 6
Antigüedad: 18 años, 10 meses
Puntos: 0
hola que tal... Mi opinion al respecto es la siguiente...

Definitivamente la arquitectura basada en 3 capas es una muy buena practica... cuando las aplicaciones involucradas asi lo requieren... es justificado su implementacion. Pero no en todas la ocasion es indispensable.
Hay que ponerser desde el punto de vista de la eficiencia igual... imaginemos que tenemos una conexion a una base de datos remota. Creo que hay ocasiones en las que no es justificado tantas restricciones a la hora de la elaboracion del diseño de una aplicacion...

Esto parece cuestion de una paranoia como bien mencionas... es como si para realizar una pequeña aplicacion en consola... o una aplicacion que realice algunas simples operaciones .... tuvieramos que hacer todos los diagramas que dicta el UML. Simplemente con trata de aplicar todas estas practicas nos llevariamos mucho mas tiempo de lo que la aplicacion en si... solo hay que aplicarlos cuando sea necesario.

Yo creo que todo debe de tener un equilibrio, tanto las buenas practicas, como el sentido comun para hacer las cosas.
En este ejemplo que muestras yo no veo nigun inconveniente por hacer la sumatoria en el procedimiento almacenado... quizá el unico inconveniente seria si migraras tu aplicacion a otro manejador de base de datos... tus procedmientos almacenados lo mas probable es que tengas que rehacerlos...

Bueno esa es mi opinion
Un saludo a todos
  #3 (permalink)  
Antiguo 26/04/2006, 11:38
Avatar de TolaWare
Colaborador
 
Fecha de Ingreso: julio-2005
Mensajes: 4.352
Antigüedad: 19 años, 4 meses
Puntos: 24
MMMM, creo que uno de los principales objetivos del diseño en capas, es el orden, y la separación de conceptos y creo que es beneficioso en casi cualquier aplicación. El ahorro de tiempo que te trae no hacer capas ahora, es un gasto de tiempo en mantenimiento mañana.
Rodolfo: si ya bienes diseñando tu aplicacion respetando la arquitectura de 3 capas, pues te recomiendo que el metodo lo implementes en la capa del negocio.

Saludos
__________________
http://blog.tolaware.com.ar -> Blog de Java, Ruby y Linux
Atención: Estás leyendo un tema que no tiene actividad desde hace más de 6 MESES, te recomendamos abrir un Nuevo tema en lugar de responder al actual.
Respuesta




La zona horaria es GMT -6. Ahora son las 22:26.