none
¿Donde es mejor validar los datos a nivel de formulario o en la capa de negocios? RRS feed

  • Pregunta

  • Hola:

     

    No se donde es mejor validar los datos si en el formulario o en la capa de negocios. Si se hace en el formulario se puede hacer mediante msgbox o mediante errorprovier, pero si es mejor hacerlo desde la base de datos ¿como mandamos los mensajes al usuario? ya que al ser un proyecto sin interfac gráfica no puede mandar mensajes con msgbox.

     

    Un Saludo.

    Juan Carlos.

    viernes, 1 de octubre de 2010 15:14

Respuestas

  • hola

    en realidad lo idea seria validar en ambos lados en la presentacion los datos de input del usuario y en el negocio estos mismos datos, mas validaciones que impliquen reglas de negocio, como ser por ejemplo si hay stock para cumplir una orden de produccion, este caso como veras no se valida en el cliente porque no dispones de esa informacion

    ¿como mandamos los mensajes al usuario?

    lo envias mediante la generacion de un Exception, quizas un custom exception que crees tu mismo

    aqui se plante una pregunta similar

    http://social.msdn.microsoft.com/Forums/es-ES/vcses/thread/31410a75-d0a3-4264-b910-324fc8a576d6

    en la presentacion tomarias esa exception y la mostrarias en un MessageBox

    saludos


    Leandro Tuttini

    Blog
    Buenos Aires
    Argentina
    viernes, 1 de octubre de 2010 15:19
  • Hola, mis dos centavos.
     
    En lo personal, yo pienso como Leandro, que las validaciones hay que
    ponerlas en ambos lados. Una clase en tu capa de negocios tiene
    precondiciones bajo las cuales se puede instanciar, bajo las cuales puede
    cambiar de estado y bajo las cuales ciertos métodos se pueden ejecutar. Si
    alguna de esas precondiciones es violada, entonces debe ocurrir una
    excepción. Al hacer esto, proteges al objeto para que no vaya a quedar en un
    estado indefinido: al final, es mejor que truene la aplicación con una
    excepción (que puedes rastrear y reproducir) a que surjan bugs por estados
    inválidos que puede llegar incluso a corromper una fuente de datos (por
    ejemplo, es mejor que truene la app a que modifiques erróneamente los
    inventarios de un sistema de manejo de almacenes).
     
    Por otra parte, una de las tareas de una UI es advertirle al usuario cuándo
    la está calabaceando, cuándo los datos son erróneos, etcétera. De tal suerte
    que es responsabilidad de ésta realizar tantas validaciones de las
    precondiciones como sea posible. O en dado caso, debe de poder llamar a
    métodos de la capa de negocio que hagan esa validación (por ejemplo, para
    saber cuál es el estado del objeto y cuál es su siguiente estado válido,
    etc). Pero sobre todo debe poder anticiparse a cualquier fallo lo más que se
    pueda (muy particularmente, el ingreso de datos por parte del usuario):
    entre más se anticipe, más información puede enviarle al usuario sobre lo
    que está mal.
     
    Si dejas las validaciones solo en la capa de UI te arriesgas a que si se te
    pasa alguna, dejes el estado de la aplicación indefinido y esto es fuente de
    muchos bugs. Peor aún, si alguien quiere reutilizar tu clase de negocio, no
    hay forma de protegerla contra errores por parte del nuevo programador,
    nuevamente arriesgando el estado indefinido.
     
    Ya para finalizar. Si no quieres utilizar excepciones para indicar errores
    en la capa de negocio, siempre puedes utilizar observadores. En particular,
    a tu clase de negocio en cuestión añádele un event, digamos, OnError, que se
    dispare cuando se detecte algún error. Luego subscribes a tu formulario a
    ese evento y cada que se reciba puedes mostrar el mensaje de error
    correspondiente con un MessageBox.
     
    Mi opinión, al menos.
     
    Saludos.
     
     


    Fernando Gómez
    fermasmas.wordpress.com
    viernes, 1 de octubre de 2010 17:21

Todas las respuestas

  • Lo mejor es en el form!!
    Coding "La lucha diaria" - D3S........D4S
    Necesitamos un voto: Aquí
    "Ya tengo Blog :D": Primer Entrada Silverlight y WCF RIA
    • Propuesto como respuesta Felipe Sotelo S viernes, 1 de octubre de 2010 15:16
    viernes, 1 de octubre de 2010 15:16
  • hola

    en realidad lo idea seria validar en ambos lados en la presentacion los datos de input del usuario y en el negocio estos mismos datos, mas validaciones que impliquen reglas de negocio, como ser por ejemplo si hay stock para cumplir una orden de produccion, este caso como veras no se valida en el cliente porque no dispones de esa informacion

    ¿como mandamos los mensajes al usuario?

    lo envias mediante la generacion de un Exception, quizas un custom exception que crees tu mismo

    aqui se plante una pregunta similar

    http://social.msdn.microsoft.com/Forums/es-ES/vcses/thread/31410a75-d0a3-4264-b910-324fc8a576d6

    en la presentacion tomarias esa exception y la mostrarias en un MessageBox

    saludos


    Leandro Tuttini

    Blog
    Buenos Aires
    Argentina
    viernes, 1 de octubre de 2010 15:19
  • Muchas Gracias
    viernes, 1 de octubre de 2010 16:06
  • Hola, mis dos centavos.
     
    En lo personal, yo pienso como Leandro, que las validaciones hay que
    ponerlas en ambos lados. Una clase en tu capa de negocios tiene
    precondiciones bajo las cuales se puede instanciar, bajo las cuales puede
    cambiar de estado y bajo las cuales ciertos métodos se pueden ejecutar. Si
    alguna de esas precondiciones es violada, entonces debe ocurrir una
    excepción. Al hacer esto, proteges al objeto para que no vaya a quedar en un
    estado indefinido: al final, es mejor que truene la aplicación con una
    excepción (que puedes rastrear y reproducir) a que surjan bugs por estados
    inválidos que puede llegar incluso a corromper una fuente de datos (por
    ejemplo, es mejor que truene la app a que modifiques erróneamente los
    inventarios de un sistema de manejo de almacenes).
     
    Por otra parte, una de las tareas de una UI es advertirle al usuario cuándo
    la está calabaceando, cuándo los datos son erróneos, etcétera. De tal suerte
    que es responsabilidad de ésta realizar tantas validaciones de las
    precondiciones como sea posible. O en dado caso, debe de poder llamar a
    métodos de la capa de negocio que hagan esa validación (por ejemplo, para
    saber cuál es el estado del objeto y cuál es su siguiente estado válido,
    etc). Pero sobre todo debe poder anticiparse a cualquier fallo lo más que se
    pueda (muy particularmente, el ingreso de datos por parte del usuario):
    entre más se anticipe, más información puede enviarle al usuario sobre lo
    que está mal.
     
    Si dejas las validaciones solo en la capa de UI te arriesgas a que si se te
    pasa alguna, dejes el estado de la aplicación indefinido y esto es fuente de
    muchos bugs. Peor aún, si alguien quiere reutilizar tu clase de negocio, no
    hay forma de protegerla contra errores por parte del nuevo programador,
    nuevamente arriesgando el estado indefinido.
     
    Ya para finalizar. Si no quieres utilizar excepciones para indicar errores
    en la capa de negocio, siempre puedes utilizar observadores. En particular,
    a tu clase de negocio en cuestión añádele un event, digamos, OnError, que se
    dispare cuando se detecte algún error. Luego subscribes a tu formulario a
    ese evento y cada que se reciba puedes mostrar el mensaje de error
    correspondiente con un MessageBox.
     
    Mi opinión, al menos.
     
    Saludos.
     
     


    Fernando Gómez
    fermasmas.wordpress.com
    viernes, 1 de octubre de 2010 17:21
  • Bueno en mi concepto y humilde conocimiento esto aplica 100% para WEB no se que tanto para forms???

     

    Saludos


    Coding "La lucha diaria" - D3S........D4S
    Necesitamos un voto: Aquí
    "Ya tengo Blog :D": Primer Entrada Silverlight y WCF RIA
    viernes, 1 de octubre de 2010 17:25
  • A mí me gusta usar esa forma para Forms, al menos... al final, un componente
    de negocio puedes usarlo para web y para windows forms (de hecho, en un
    escenario así sería lo ideal), y pues más bien lo que varía es la forma de
    atrapar el error (i.e. en WinForms con un MessageBox y en WebForms con el
    método OnError o redirigiendo a la página genérica de errores).
     
    Otro punto adicional es que el componente de negocio, por regla general,
    debe tender a tener un bajo acoplamiento. Por lo que desde el punto de vista
    del componetne, no puede darse el lujo de que alguien más valide sus
    precondiciones... so riesgo de dejar el sistema en estado indefinido, o
    peor).
     
    Methinks...
     
    Saludos.
     
     


    Fernando Gómez
    fermasmas.wordpress.com
    viernes, 1 de octubre de 2010 17:50
  • hola Leandro, me podrias decir a que te refieres cuando dices: "en realidad lo idea seria validar en ambos lados en la presentacion los datos de input del usuario y en el negocio estos mismos datos, mas validaciones que impliquen reglas de negocio ...". Por ejemplo yo tengo una pantalla de altas de chequeras entonces debo completar distintos datos, hay un campo que pide asociar la chequera a una cuenta, entonces yo valido en la capa de presentacion que solo se ingresen letras en la descripcion de la cuenta, pero segun dices tambien deberia de hacer esta validacion en la capa logica, validando 2 veces lo mismo. Lo que si valido en la capa logica es que exista esa cuenta, pero no que haya ingresado letras. Me podrias ayudar con un ejemplo, gracias.
    jueves, 28 de octubre de 2010 15:49