none
Ayuda con ASP.NET MVC RRS feed

  • Pregunta

  • Hola amigos Tengo algunas dudas sobre si mi proyecto de pasantia que estoy realizando para la Universidad, lo estoy realizando correctamente con el modelo MVC??

    La conexion a la base de datos la hago por medio de un controlador (CONTROLBD)

    tengo unos servicios que envian datos a la BD por medio del controlador

    este es el codigo de dos de ellos

    using System;
    
    using System.Collections;
    
    using System.Linq;
    
    using System.Web;
    
    using System.Web.Services;
    
    using System.Web.Services.Protocols;
    
    using System.Xml.Linq;
    
    using System.Data;
    
    
    
    
    
    /// <summary>
    
    /// Descripción breve de WS_Crediponte
    
    /// </summary>
    
    
    
    namespace Logica
    
    {
    
    
    
     [WebService(Namespace = "http://tempuri.org/")]
    
     [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
    
     // Para permitir que se llame a este servicio web desde un script, usando ASP.NET AJAX, quite la marca de comentario de la línea siguiente. 
    
     //[System.Web.Script.Services.ScriptService]
    
     public class WS_Crediponte : System.Web.Services.WebService
    
     {
    
    
    
      public WS_Crediponte()
    
      {
    
    
    
    
     public DataSet Consulta_Cliente(int ide)
    
      {
    
       string Sql;
    
       Sql = " SELECT CLIENTE.CEDULA_CLIENTE,UPPER(CLIENTE.NOMBRES),UPPER(CLIENTE.APELLIDOS),UPPER(CLIENTE.DIRECCION),CLIENTE.TELEFONO,UPPER(CLIENTE.OCUPACION) ";
    
       Sql += " FROM CLIENTE";
    
       Sql += " WHERE CEDULA_CLIENTE = " + ide;
    
       Servicios.ControlBD Obj = new Servicios.ControlBD();
    
       return Obj.select(Sql, "CLIENTE");
    
      }
    
      
    
    
    
      // REFERENCIA WEB PARA INSERTAR UN CLIENTE
    
      [WebMethod]
    
      public void Nuevo_Cliente(int ced,int tipo_doc,int cod_depto,int cod_muni,int cod_est_civil,int cod_sexo,string nom,string apel,string dir,string tel,string fec_nac, string ocupa,string nom_cony,string apel_cony,string ced_cony,string cap_pag )
    
      {
    
       string Sql;
    
       Sql = " insert into CLIENTE (CEDULA_CLIENTE,COD_TIP_DOC,COD_DEPTO,COD_MUNICIPIO,COD_ESTADO_CIVIL,COD_SEXO,NOMBRES,APELLIDOS,DIRECCION,TELEFONO,FECHA_NACIMIENTO,OCUPACION,NOMBRES_CONYUGUE,APELLIDOS_CONYUGUE,IDENTIFICACION_CONYUGUE,CAPACIDAD_DE_PAGO )";
    
       Sql += " values (" + ced + "," + tipo_doc + "," + cod_depto + "," + cod_muni + "," + cod_est_civil + "," + cod_sexo + ",'" + nom + "','" + apel + "','" + dir + "','" + tel + "','" + fec_nac + "','" + ocupa + "','" + nom_cony + "','" + apel_cony + "','" + ced_cony + "','" + cap_pag + "' )";
    
       Servicios.ControlBD Obj = new Servicios.ControlBD();
    
       Obj.ejecutar(Sql);
    
      }}
    
    

    despues en un Webform en el codebehind invoco el servicio

    public partial class Crear_Cliente : System.Web.UI.Page
    
    {
    
     protected void Page_Load(object sender, EventArgs e)
    
     {
    
    
    
     }
    
     protected void Btn_Enviar_Click(object sender, EventArgs e)
    
     {
    
      Rw_Crediponte.WS_Crediponte Rw = new Rw_Crediponte.WS_Crediponte();
    
      Rw.Nuevo_Cliente(Convert.ToInt32( Txt_Ced.Text),Convert.ToInt32( DrDl_Tip_Doc.SelectedValue),Convert.ToInt32( DrDL_DEPTO.SelectedValue),Convert.ToInt32( DrDL_MPIO.SelectedValue),Convert.ToInt32( DrDL_ESTADOCIVIL.SelectedValue),Convert.ToInt32( DrDL_Sexo.SelectedValue),Txt_Nom.Text,Txt_Apel.Text,Txt_Dir.Text,Txt_Tel_Cli.Text,Txt_Fec_Nac.Text,Txt_Ocupa.Text,Txt_Nom_Cony.Text,Txt_Apel_Cony.Text,Txt_Ced_Cony.Text,Txt_Cap_Pago.Text);
    
      Response.Redirect("~/Comprobacion.aspx");
    
     }
    
    

    por ultimo en la vista ingreso los textbox para capturar los datos del usuario

    de antemano muchas gracias por aclarar mis dudas

     

    domingo, 12 de diciembre de 2010 23:42

Respuestas

  • >Crear_solicitud.cs que vendría siendo?

    Buena pregunta... Usas Webforms, por lo que en el Code Behind puedes meter cualquier cosa, puedes meter allí la lógica de negocio. Pero no es el mejor sitio donde ponerla. Por que no? En general debido a temas de escalibilidad y prueba de tu código.

    Lo ideal a poner el el Code Behind es lógica de presentación y las llamadas a la lógica de negocio. La lógica de presentación es una capa nueva (aunque cuando hablamos de 3 capas la incluimos dentro de la capa de presentación), y es la que toma las decisiones tipo: habilitar un control cuando otro se llena. Mostrar en rojo los campos erróneos, deshabilitar el botón de enviar si el formulario no está completo, etc, etc. Es decir toma decisiones de como la presentación debe actuar para mostrar los datos que hay en cada momento.

    Así, en mi opinión y con el trozo de código visto:

    1. Crear_solicitud.aspx + Crear_solicitud.aspx.cx -> Presentación (+ lógica de presentación)
    2. WS_Crediponte: Acceso a datos

    Y es que, con el código pasado, no tienes lógica de negocio.

    P.ej. donde pondrías código que comprobase que cuando se solicita un crédito el monto no es negativo? Eso es lógica de negocio, porque tu negocio impide solicitar créditos con montos negativos.

    Podrías decir: Ah... lo valido en Crear_solicitud.cs y listos. Pero eso es mala idea. Por que? Pues porque entonces si tienes otra página que también te permite pedir créditos deberás repetir esta validación. De ahí que surge la necesidad de una capa adicional.

    En principio, desde un punto de visto arquitectónico, si expones servicios web, lo que expones a través de ellos no suele ser el acceso a datos (usualmente no quieres que alguien acceda a la BBDD tal cual). Lo que expones es la lógica de negocio. Allí validas lo que sea y si todo está ok (de acuerdo con tus reglas) envías la petición a la capa de datos.

    Luego ya a nivel de implementación la capa de datos puede estar en otra máquina (y puedes tener comunicación via web services (pero internos, protegidos por firewall) u otros mecanismos como rpc) o bien en la misma máquina y ser simplemente un conjunto de clases. Eso ya forma parte de la arquitectura de tu aplicación y son decisiones que se toman en base a escalabilidad, rendimiento, disponibilidad y mantenibilidad de tu aplicación. A nivel lógico (que es de lo que estamos hablando) se trata de que:

    1. Tienes un conjunto de WebForms con tu presentación (y la lógica asociada tipo habilitar/deshabilitar campos)
    2. Tienes un conjunto de clases que son lógica de negocio. Se llaman solamente des del code behind de los webforms. Validan que todo sea correcto.
    3. Tienes otro conjunto de clases que son acceso a datos. Acceden a la bbdd y se llaman solamente desde las clases de lógica de negocio.

    Un saludo!


    Eduard Tomàs Blog: http://geeks.ms/blogs/etomas -- Twitter: eiximenis

    Hola Eduard

    Gracias amigo me has aclarado muchas dudas que tenia ahora ya todo esta claro.

    un saludo desde colombia 


    Victor Sevilla Ordoñez Colombia
    miércoles, 15 de diciembre de 2010 14:59

Todas las respuestas

  • Buenas.

    No :)

    Por lo que veo no estás usando ASP.NET MVC, estás usando Webforms, puestp que tienes eventos como Btn_Enviar_Click. Eso no lo tenemos en MVC.

    Vayamos por partes! ;-)

    1. Lo que tu llamas "Controlador" no es un controlador de MVC, es un conjunto de servicios Web
    2. Tus páginas deben ser webforms tradicionales con un <asp:Button> en el cual en su evento _Click() llamas a tu servicios web.

    La diferencia fundamental de MVC con webforms es que en MVC no tenemos code behind (nada de .aspx.cs para entendernos). Y no ,lo tenemos porque no es necesario: en MVC la vista se encarga de presentación sólamente y el controlador (junto con el modelo) de la lógica y la interacción.

    El precio a pagar es que NO tenemos controles, si por controles entendemos lo que se entiende normalmente: Arrastrar algo desde la toolbox y usar una ventana de propiedades. Olvídate de eso en MVC: ni toolbox, ni ventana de propiedades.

    Como podrías hacer algo parecido a lo que quieres hacer?

    Pues bien, por un lado puedes olvidar todos esos servicios web (de hecho, tampoco en webforms los necesitas). Lo que necesitas básicamente es:

    1. Un controlador que defina una acción, accesible a través de los 2 verbos http (GET y POST). Acceder a la acción usando GET devolverá la vista de ingreso de datos. Esta vista es básicamente un <form>. Submitear el formulario a la misma URL, usando POST lo que hará será guardar los datos en la BBDD. El esquema de código es:
    public class ClientesController : Controller
    {
      public ActionResult Nuevo()
      {
         return View();
      }
    
      [HttpPost]
      public ActionResult Nuevo(Cliente c)
      {
         // Insertar el cliente en la BBDD
         
         // Redirigir el usuario a /home/index
         return RedirectToAction("Index","Home")
      }
    }
    

    Con esto, yendo a /Clientes/Nuevo verás la vista de inserción de datos. Dicha vista debería tener un formulario, algo parecido a:

    <form method="post">
      <input type="text" name="Nombre" /> <br />
      <input type="text" name="Apellido" /> <br />
      <input type="submit" />
    </form>
    

    Luego la clase "Cliente" es la que te permite que MVC reciba los datos. Para ello te basta que las propiedades de Cliente se llamen igual que los distintos valores de los atributos "name" de tu formulario. En nuestro caso:

    public class Cliente
    {
      public string Nombre {get; set;}
      public string Apellido {get; set;}
    }
    

    Cuando el usuario haga submit del form, MVC recibirá los datos y invocará el método Nuevo(Cliente c) del controlador (pq vamos via post) y desde allí tu ya podrías hacer lo que quieras con tu cliente.

    Echale un vistazo a los tutoriales de http://asp.net/mvc que explican eso que te he dicho yo, pero más "paso a paso" :)

    Saludos! 


    Eduard Tomàs Blog: http://geeks.ms/blogs/etomas -- Twitter: eiximenis
    • Propuesto como respuesta jtorrecilla miércoles, 15 de diciembre de 2010 15:39
    lunes, 13 de diciembre de 2010 9:14
  • Buenas.

    No :)

    Por lo que veo no estás usando ASP.NET MVC, estás usando Webforms, puestp que tienes eventos como Btn_Enviar_Click. Eso no lo tenemos en MVC.

    Vayamos por partes! ;-)

    1. Lo que tu llamas "Controlador" no es un controlador de MVC, es un conjunto de servicios Web
    2. Tus páginas deben ser webforms tradicionales con un <asp:Button> en el cual en su evento _Click() llamas a tu servicios web.

    La diferencia fundamental de MVC con webforms es que en MVC no tenemos code behind (nada de .aspx.cs para entendernos). Y no ,lo tenemos porque no es necesario: en MVC la vista se encarga de presentación sólamente y el controlador (junto con el modelo) de la lógica y la interacción.

    El precio a pagar es que NO tenemos controles , si por controles entendemos lo que se entiende normalmente: Arrastrar algo desde la toolbox y usar una ventana de propiedades. Olvídate de eso en MVC: ni toolbox, ni ventana de propiedades.

    Como podrías hacer algo parecido a lo que quieres hacer?

    Pues bien, por un lado puedes olvidar todos esos servicios web (de hecho, tampoco en webforms los necesitas). Lo que necesitas básicamente es:

    1. Un controlador que defina una acción , accesible a través de los 2 verbos http (GET y POST). Acceder a la acción usando GET devolverá la vista de ingreso de datos. Esta vista es básicamente un <form>. Submitear el formulario a la misma URL, usando POST lo que hará será guardar los datos en la BBDD. El esquema de código es:
    public
     class
     ClientesController : Controller
    {
     public
     ActionResult Nuevo()
     {
       return
     View();
     }
    
     [HttpPost]
     public
     ActionResult Nuevo(Cliente c)
     {
       // Insertar el cliente en la BBDD
    
       
       // Redirigir el usuario a /home/index
    
       return
     RedirectToAction("Index"
    ,"Home"
    )
     }
    }
    

    Con esto, yendo a /Clientes/Nuevo verás la vista de inserción de datos. Dicha vista debería tener un formulario, algo parecido a:

    <
    form
     method
    =
    "post"
    >
    
     <
    input
     type
    =
    "text"
     name
    =
    "Nombre"
     />
     <
    br
     />
    
     <
    input
     type
    =
    "text"
     name
    =
    "Apellido"
     />
     <
    br
     />
    
     <
    input
     type
    =
    "submit"
     />
    
    </
    form
    >
    
    

    Luego la clase "Cliente" es la que te permite que MVC reciba los datos. Para ello te basta que las propiedades de Cliente se llamen igual que los distintos valores de los atributos "name" de tu formulario. En nuestro caso:

    public
     class
     Cliente
    {
     public
     string
     Nombre {get
    ; set
    ;}
     public
     string
     Apellido {get
    ; set
    ;}
    }
    

    Cuando el usuario haga submit del form, MVC recibirá los datos y invocará el método Nuevo(Cliente c) del controlador (pq vamos via post) y desde allí tu ya podrías hacer lo que quieras con tu cliente.

    Echale un vistazo a los tutoriales de http://asp.net/mvc  que explican eso que te he dicho yo, pero más "paso a paso" :)

    Saludos! 


    Eduard Tomàs Blog: http://geeks.ms/blogs/etomas -- Twitter: eiximenis


    Amigo te agradezco por tu respuesta

    me ha quedado todo muy claro y estuve leyendo sobre MVC y en realidad esta claro que no lo he aplicado.

    Otra pregunta : En el proyecto que nos piden en la universidad no necesaroiamente debe ser aplicando el patron MVC pero si se debe separar por capas (Capa de datos,Capa de Negocio,Capa de presentacion) ¿segun lo que viste si se consideraria modelo a 3 capas no importa si estoy o n aplicando MVC?

     

    Muchas gracias

    lunes, 13 de diciembre de 2010 16:58
  • @Víctor,

    Las capas si las estás separando parcialmente. La separación por capas, básicamente dice que debes tener separado el código que se encarga de presentación, de lógica y de acceso a datos.

    Por lo que veo en tu caso tienes la presentación en la página .aspx y el acceso a datos en la clase WS_Crediponte. No hay lógica (ni lugar donde ponerla)

    Primero un par de temas de arquitectura:

    1. Estrictamente no es necesario que hagas servicios web. Eso, evidentemente, depende de las necesidades finales que tu arquitectura deba soportar. Servicios web son para habilitar acceso remoto: es decir, básicamente, para invocar servicios que están (o podrían estar) en otra máquina. En tu caso tienes una aplicación web. Eso significa, que en principio todo el código se ejecuta en servidor, por lo que no necesitas web services para acceder de un cliente a un servidor. Eso sería distinto en el caso de una app de escritorio, donde hay un proceso (.exe) que se ejecuta en máquina cliente, y si debes comunicarte con un servidor necesitas servicios web. En apps web no es así, puesto que el browser ya se encarga de esto.
    2. Eso NO significa que estén mal, te puede interesar para tener los servicios web accesibles por otros clientes, para separarlos en distintas máquinas, etc

    Con eso quiero decir que una separación por capas no te obliga al uso de servicios web. Es un tema arquitectónico. Lo que sí se suele hacer, es que si hay web services estos implementan la capa de lógica de negocio (o un wrapper por encima de ella).

    Dicho esto, si quieres usar una separación en capas, te falta la capa de lógica de negocio. Tienes tus servicios web (clase WS_Crediponte) dentro de un namespace llamado Logica, pero WS_Crediponte está actuando como acceso a datos (sólo hace inserts y selects).

    Para que eso fuese con 3 capas, yo haría lo siguiente:

    1. Crearia una clase nueva (llamada p.ej. CrediponteBd) con métodos para acceder a la BBDD. P.ej. un método Nuevo_Cliente, que de hecho sería el que hay ahora en WS_Crediponte.
    2. Des del método Nuevo_Cliente que está en WS_Crediponte lo que haría es: Crear un objeto CrediponteBd y llamar al método Nuevo_Cliente del objeto CrediponteBd

    ¿Y para que esto? Pues bien, en WS_Crediponte debería haber la lógica de negocio. P.ej. no es válido añadir un cliente con un nombre vacío? Pues es en WS_Crediponte donde se comprueba eso. Resumiendo: WS_Crediponte hace todas las comprobaciones de lógica y si todo es correcto, llama al método Nuevo_Cliente de CrediponteBd. Ese método añade el cliente sin preocuparse de nada porque ya sabe que todo es correcto.

    Eso vendría a ser separación en 3 capas:

    • Presentación: Tu página .aspx
    • Lógica: Tu servicio web WS_Crediponte
    • Acceso a datos: La nueva clase CrediponteBd

    Un saludo!


    Eduard Tomàs Blog: http://geeks.ms/blogs/etomas -- Twitter: eiximenis
    • Propuesto como respuesta jtorrecilla miércoles, 15 de diciembre de 2010 15:39
    martes, 14 de diciembre de 2010 7:26
  • @Víctor,

    Las capas si las estás separando parcialmente. La separación por capas, básicamente dice que debes tener separado el código que se encarga de presentación, de lógica y de acceso a datos.

    Por lo que veo en tu caso tienes la presentación en la página .aspx y el acceso a datos en la clase WS_Crediponte. No hay lógica (ni lugar donde ponerla)

    Primero un par de temas de arquitectura:

    1. Estrictamente no es necesario que hagas servicios web. Eso, evidentemente, depende de las necesidades finales que tu arquitectura deba soportar. Servicios web son para habilitar acceso remoto: es decir, básicamente, para invocar servicios que están (o podrían estar) en otra máquina. En tu caso tienes una aplicación web. Eso significa, que en principio todo el código se ejecuta en servidor, por lo que no necesitas web services para acceder de un cliente a un servidor. Eso sería distinto en el caso de una app de escritorio, donde hay un proceso (.exe) que se ejecuta en máquina cliente, y si debes comunicarte con un servidor necesitas servicios web. En apps web no es así, puesto que el browser ya se encarga de esto.
    2. Eso NO significa que estén mal, te puede interesar para tener los servicios web accesibles por otros clientes, para separarlos en distintas máquinas, etc

    Con eso quiero decir que una separación por capas no te obliga al uso de servicios web. Es un tema arquitectónico. Lo que sí se suele hacer, es que si hay web services estos implementan la capa de lógica de negocio (o un wrapper por encima de ella).

    Dicho esto, si quieres usar una separación en capas, te falta la capa de lógica de negocio. Tienes tus servicios web (clase WS_Crediponte) dentro de un namespace llamado Logica, pero WS_Crediponte está actuando como acceso a datos (sólo hace inserts y selects).

    Para que eso fuese con 3 capas, yo haría lo siguiente:

    1. Crearia una clase nueva (llamada p.ej. CrediponteBd) con métodos para acceder a la BBDD. P.ej. un método Nuevo_Cliente, que de hecho sería el que hay ahora en WS_Crediponte.
    2. Des del método Nuevo_Cliente que está en WS_Crediponte lo que haría es: Crear un objeto CrediponteBd y llamar al método Nuevo_Cliente del objeto CrediponteBd

    ¿Y para que esto? Pues bien, en WS_Crediponte debería haber la lógica de negocio. P.ej. no es válido añadir un cliente con un nombre vacío? Pues es en WS_Crediponte donde se comprueba eso. Resumiendo: WS_Crediponte hace todas las comprobaciones de lógica y si todo es correcto, llama al método Nuevo_Cliente de CrediponteBd. Ese método añade el cliente sin preocuparse de nada porque ya sabe que todo es correcto.

    Eso vendría a ser separación en 3 capas:

    • Presentación: Tu página .aspx
    • Lógica: Tu servicio web WS_Crediponte
    • Acceso a datos: La nueva clase CrediponteBd

    Un saludo!


    Eduard Tomàs Blog: http://geeks.ms/blogs/etomas -- Twitter: eiximenis


    Hola Eduard nuevamente greacias por aclarar mis dudas ya me esta quedando mas claro

    mira osea que lo que yo llamo WS_CREDIPONTE es el acceso a datos pero yo desde el CODEBEHIND de un WebForm por ejemplo el WebForm Crear_Solicitud.aspx Tiene todos los controles para que el usuario ingrese los datos pero yo desde el CodeBehind de ese WebForm Llamo al servicio que esta en WS_CREDIPONTE osea Solicitud_Credito  

    te muestro un ejemplo

    ESTO ESTA EN WS_CREEDIPONTE OSEA EL ACCESO A DATOS

    //REFERENCIA WEB PARA CREAR UNA SOLICITUD DE CREDITO
        [WebMethod]
        public void Solicitud_Credito(int Cod_Prod,int Cod_Zona,int Ced_Cli,int Monto,int Plazo_Sol,string Fec_Sol, string Resp_Sol)
        {
          string Sql;
          Sql = " insert into SOLICITUD (COD_PRODUCTO,COD_ZONA,CEDULA_CLIENTE,MONTO_SOLICITUD,PLAZO_SOLICITUD,FECHA_SOLICITUD,RESPONSABLE_SOLICITUD )";
          Sql += " values (" + Cod_Prod + "," + Cod_Zona + "," + Ced_Cli + ",'" + Monto + "','" + Plazo_Sol + "','" + Fec_Sol + "','" + Resp_Sol + "' )";
          Servicios.ControlBD Obj = new Servicios.ControlBD();
          Obj.ejecutar(Sql);
        }
    

    PERO DESDE EL CODEBEHIND de un WEBFORM que se llama Crear_Solicitud llamo a Solicitud_Credito que esta en el acceso a datos te muestro el codigo

    using System;
    using System.Collections;
    using System.Configuration;
    using System.Data;
    using System.Linq;
    using System.Web;
    using System.Web.Security;
    using System.Web.UI;
    using System.Web.UI.HtmlControls;
    using System.Web.UI.WebControls;
    using System.Web.UI.WebControls.WebParts;
    using System.Xml.Linq;
    
    public partial class Crear_Solicitud : System.Web.UI.Page
    {
      protected void Page_Load(object sender, EventArgs e)
      {
    
      }
      protected void Button1_Click(object sender, EventArgs e)
      {
        DataSet Ds_Consul_Cliente;
        Rw_Crediponte.WS_Crediponte Rw = new Rw_Crediponte.WS_Crediponte();
    
        try 
        {
    
          Ds_Consul_Cliente = Rw.Consulta_Cliente(Convert.ToInt32(Txt_Ced_Cli.Text));
    
          if (Ds_Consul_Cliente.Tables[0].Rows.Count == 0)
          {
            Lb_Error.Visible = true;
          }
          else
          {
            Rw.Solicitud_Credito(Convert.ToInt32(Dr_Dl_Valor.SelectedValue), Convert.ToInt32(Dr_Dl_Zona_Soli.SelectedValue), Convert.ToInt32(Txt_Ced_Cli.Text), Convert.ToInt32(Dr_Dl_Valor.SelectedItem.Text), Convert.ToInt32(DrDL_Plazo_Sol.SelectedValue), Txt_Fecha_Sol.Text, Txt_Responsable_Sol.Text);
            Response.Redirect("~/Comprobacion.aspx");
            Lb_Error.Visible = false;
          }
        
        }
        catch (System.OverflowException)
          
       {
         Lb_Error.Visible = false;
       }
    

    Mi pregunta es la siguiente: ¿Si WS_Crediponte es la capa de acceso  a datos, entonces Crear_solicitud.cs que vendria siendo?

    Gracias..


    Victor Sevilla Ordoñez Colombia
    martes, 14 de diciembre de 2010 17:18
  • >Crear_solicitud.cs que vendría siendo?

    Buena pregunta... Usas Webforms, por lo que en el Code Behind puedes meter cualquier cosa, puedes meter allí la lógica de negocio. Pero no es el mejor sitio donde ponerla. Por que no? En general debido a temas de escalibilidad y prueba de tu código.

    Lo ideal a poner el el Code Behind es lógica de presentación y las llamadas a la lógica de negocio. La lógica de presentación es una capa nueva (aunque cuando hablamos de 3 capas la incluimos dentro de la capa de presentación), y es la que toma las decisiones tipo: habilitar un control cuando otro se llena. Mostrar en rojo los campos erróneos, deshabilitar el botón de enviar si el formulario no está completo, etc, etc. Es decir toma decisiones de como la presentación debe actuar para mostrar los datos que hay en cada momento.

    Así, en mi opinión y con el trozo de código visto:

    1. Crear_solicitud.aspx + Crear_solicitud.aspx.cx -> Presentación (+ lógica de presentación)
    2. WS_Crediponte: Acceso a datos

    Y es que, con el código pasado, no tienes lógica de negocio.

    P.ej. donde pondrías código que comprobase que cuando se solicita un crédito el monto no es negativo? Eso es lógica de negocio, porque tu negocio impide solicitar créditos con montos negativos.

    Podrías decir: Ah... lo valido en Crear_solicitud.cs y listos. Pero eso es mala idea. Por que? Pues porque entonces si tienes otra página que también te permite pedir créditos deberás repetir esta validación. De ahí que surge la necesidad de una capa adicional.

    En principio, desde un punto de visto arquitectónico, si expones servicios web, lo que expones a través de ellos no suele ser el acceso a datos (usualmente no quieres que alguien acceda a la BBDD tal cual). Lo que expones es la lógica de negocio. Allí validas lo que sea y si todo está ok (de acuerdo con tus reglas) envías la petición a la capa de datos.

    Luego ya a nivel de implementación la capa de datos puede estar en otra máquina (y puedes tener comunicación via web services (pero internos, protegidos por firewall) u otros mecanismos como rpc) o bien en la misma máquina y ser simplemente un conjunto de clases. Eso ya forma parte de la arquitectura de tu aplicación y son decisiones que se toman en base a escalabilidad, rendimiento, disponibilidad y mantenibilidad de tu aplicación. A nivel lógico (que es de lo que estamos hablando) se trata de que:

    1. Tienes un conjunto de WebForms con tu presentación (y la lógica asociada tipo habilitar/deshabilitar campos)
    2. Tienes un conjunto de clases que son lógica de negocio. Se llaman solamente des del code behind de los webforms. Validan que todo sea correcto.
    3. Tienes otro conjunto de clases que son acceso a datos. Acceden a la bbdd y se llaman solamente desde las clases de lógica de negocio.

    Un saludo!


    Eduard Tomàs Blog: http://geeks.ms/blogs/etomas -- Twitter: eiximenis
    • Propuesto como respuesta jtorrecilla miércoles, 15 de diciembre de 2010 15:39
    miércoles, 15 de diciembre de 2010 7:46
  • >Crear_solicitud.cs que vendría siendo?

    Buena pregunta... Usas Webforms, por lo que en el Code Behind puedes meter cualquier cosa, puedes meter allí la lógica de negocio. Pero no es el mejor sitio donde ponerla. Por que no? En general debido a temas de escalibilidad y prueba de tu código.

    Lo ideal a poner el el Code Behind es lógica de presentación y las llamadas a la lógica de negocio. La lógica de presentación es una capa nueva (aunque cuando hablamos de 3 capas la incluimos dentro de la capa de presentación), y es la que toma las decisiones tipo: habilitar un control cuando otro se llena. Mostrar en rojo los campos erróneos, deshabilitar el botón de enviar si el formulario no está completo, etc, etc. Es decir toma decisiones de como la presentación debe actuar para mostrar los datos que hay en cada momento.

    Así, en mi opinión y con el trozo de código visto:

    1. Crear_solicitud.aspx + Crear_solicitud.aspx.cx -> Presentación (+ lógica de presentación)
    2. WS_Crediponte: Acceso a datos

    Y es que, con el código pasado, no tienes lógica de negocio.

    P.ej. donde pondrías código que comprobase que cuando se solicita un crédito el monto no es negativo? Eso es lógica de negocio, porque tu negocio impide solicitar créditos con montos negativos.

    Podrías decir: Ah... lo valido en Crear_solicitud.cs y listos. Pero eso es mala idea. Por que? Pues porque entonces si tienes otra página que también te permite pedir créditos deberás repetir esta validación. De ahí que surge la necesidad de una capa adicional.

    En principio, desde un punto de visto arquitectónico, si expones servicios web, lo que expones a través de ellos no suele ser el acceso a datos (usualmente no quieres que alguien acceda a la BBDD tal cual). Lo que expones es la lógica de negocio. Allí validas lo que sea y si todo está ok (de acuerdo con tus reglas) envías la petición a la capa de datos.

    Luego ya a nivel de implementación la capa de datos puede estar en otra máquina (y puedes tener comunicación via web services (pero internos, protegidos por firewall) u otros mecanismos como rpc) o bien en la misma máquina y ser simplemente un conjunto de clases. Eso ya forma parte de la arquitectura de tu aplicación y son decisiones que se toman en base a escalabilidad, rendimiento, disponibilidad y mantenibilidad de tu aplicación. A nivel lógico (que es de lo que estamos hablando) se trata de que:

    1. Tienes un conjunto de WebForms con tu presentación (y la lógica asociada tipo habilitar/deshabilitar campos)
    2. Tienes un conjunto de clases que son lógica de negocio. Se llaman solamente des del code behind de los webforms. Validan que todo sea correcto.
    3. Tienes otro conjunto de clases que son acceso a datos. Acceden a la bbdd y se llaman solamente desde las clases de lógica de negocio.

    Un saludo!


    Eduard Tomàs Blog: http://geeks.ms/blogs/etomas -- Twitter: eiximenis

    Hola Eduard

    Gracias amigo me has aclarado muchas dudas que tenia ahora ya todo esta claro.

    un saludo desde colombia 


    Victor Sevilla Ordoñez Colombia
    miércoles, 15 de diciembre de 2010 14:59