none
como programar orientado a objetos y en capas RRS feed

  • Pregunta

  • estoy leyendo sobre programacion orientada a objetos , algo de uml, y he visto algo de tres capas en una aplicacion web.

    en teoria parece facil pero cuando quiero ir a la practica se me complica. me gustaria si alguien me puede dar un ejemplo sencillo o me puede explicar como se hace por ejemplo si tengo un objeto factura (este objeto tiene una relacion de composicion con el objeto detallefactura) como tendria que realizar las clases que declaran los objetos y como usarlas .

     

    tablas de la base :

    factura(campos:numerofactura, sucursal,puesto, tipo,letra, fecha, cliente,subtotal, totalfactura)

    detallefactura (campos:numero,sucursal, puesto, tipo, letra, codigoarticulo, cantidad, precio, codiva)

    clientes(campos:cliente, apellidonombre, direccion, codpostal, saldo)

     

    si me pueden pasar como diseñarian ustedes estas tablas desde el diseño hasta la implementacion

     

    desde ya muchas gracias

     

     

     

    viernes, 7 de diciembre de 2007 12:06

Respuestas

  •  

    Hola Rodrigo,

     

    Deberias de revisar esta aplicación estandar de ejemplo que esta diseñada para mostrar las mejores prácticas para construir aplicaciones empresariales n-capas en .Net 2.0.

     

    Descarga el código y lee el articulo y si tienes alguna inquietud, me comentas.

     

    http://msdn2.microsoft.com/en-us/library/aa479070.aspx

     

     

    Respecto a la pregunta que hiciste, creo que lo implementaria de la siguiente forma:

     

    La estructura de tablas seria esta:

    FACTURA

     

    numerofactura   -- Llave primaria

    sucursal

    puesto

    tipo

    letra

    fecha

    cliente

    subtotal

    totalfactura

     

    Haria la relación entre Factura y DetalleFactura donde la llave primaria numeroFactura de la tabla Factura viajara a la tabla DetalleFactura y quedara como llave foranea. Para formar una llave única en la tabla DetalleFactura pondria un numero que identifique el detalle de la factura y el numero de la factura como llaves primarias.

     

    DETALLE FACTURA

     

    numero           -- Llave Primaria

    numerofactura -- Llave Primaria, Llave Foranea

    codigoarticulo

    cantidad

    precio

    codiva

     

    A la hora de mapear estas tablas a clases, crearia una clase con solo propiedades (Get y Set) para cada tabla. Por lo tanto, existiria una clase FacturaInfo.cs y otra DetalleFacturaInfo.cs:

     

    La clase DetalleFacturaInfo seria de esta forma:

     

    public class DetalleFacturaInfo

    {

      // Internal member variables
      private string _numero;
      private string _codigoArticulo;
      private int _cantidad;
      private decimal _precio;

      private int _codIva;

     

    public DetalleFacturaInfo(){}

    ...


      // Properties
      public string NumeroFactura {
       get { return _id; }
       set { _id = value; }
      }

     

    //Todas las propiedades que expongan los campos privados definidos en la parte superior de esta clase

     

      public decimal Precio{
       get { return _precio; }
       set { _precio= value; }
      }

     

      public decimal SubTotal {
       get { return _precio* _cantidad; }
      }

    }

     

    y la clase FacturaInfo.cs seria de esta forma:

     

    public class FacturaInfo

    {

      // Internal member variables
      private string _numerofactura;
      private string _sucursal;

      private string _puesto;
      private string _tipo;

      private string _letra;
      private string _fecha;
      private ClienteInfo _cliente;
      private List<DetalleFacturaInfo> _detalleFactura; //Colección de objetos DetalleFactura(Articulos de la factura)

      private decimal _totalFactura;

     

    //Constructor

    public FacturaInfo(){}

    ...


      // Properties
      public string NumeroFactura {
       get { return _id; }
       set { _id = value; }
      }

     

      public List<DetalleFacturaInfo> DetalleFactura{
       get { return _detalleFactura; }
       set { _detalleFactura= value; }
      }

     

    //Todas las propiedades que expongan los campos privados definidos en la parte superior de esta clase

    }

    Para ver esto con mayor claridad, y como se implementaria las otras capas, podes revisar el link que te pase. En este link se ve claramente la arquitectura de como se debe montar las aplicaciones con .Net.

     

    Si tienes alguna duda o inquietud, con gusto la atendere

     

    Saludos... 

     

     

    martes, 11 de diciembre de 2007 18:49
  • hola juancho gracias por tu decidacion a mi tema te lo agradezco. me resulto muy util tu ejemplo y a la aplicacion del link ya la baje solo me queda analizarla.

    por ahora te hago otra pregunta , con respecto a los metodos de las clases factura y detalle donde los creo?, en la misma clase de cada una o para trabajar en capas deberia crearlos en otras clases . he visto una aplicacion en capas y las clases entidades solo tienen las propiedades del objeto y dentro de esta clase cuando se quiere usar un metodo se crea un objeto a partir de una clase de la capa de negocio y se utilizan sus metodos, seria algo asi?

     

    gracias 

    miércoles, 12 de diciembre de 2007 12:13
  •  

    Hola Rodrigo,

     

    Si, asi seria. Piensa en los objetos entidades (FacturaInfo.cs y DetalleFacturaInfo.cs) como objetos de transferencia (Transfer Objects), los cuales tu puedes pasar o comunicar entre capas. Es decir, tu vas a poder crear instancias de estos objetos desde la capa de presentación, logica del negocio y acceso a datos. Estos objetos no tendran ningún método, solamente los campos privados, constructores y propiedades.  Desde la capa de lógica del negocio tal como tu lo dijiste, tendras una clase que contenga los servicios u operaciones de estos objectos. Es decir, puedes tener una clase Factura.cs en la capa del negocio que exponga los métodos de InserarFactura, ObtenerFacturas, etc...

     

    Mas o menos, asi quedaria la clase en la lógica del negocio:

     

    public class Factura

    {

              //Recibe como parametro un objeto entidad FacturaInfo

    public void InsertarFactura(FacturaInfo factura)

    {

      ...

    }

     

    public List<FacturaInfo> ObtenerFacturas()

    {

     ...

    }

     

    }

     

    Interesante que revises el patron de diseño de software Factory que tambien lo implementan en la aplicacíón de ejemplo que te pase.

     

    Saludos...

     

    miércoles, 12 de diciembre de 2007 13:39
  • Hola Rodrigo,

     

    Que alegria saber que ha sido de gran utilidad este post, eso es lo que uno siempre espera. OK, el factory es un patrón de diseño de software. Define una interfaz para la creación de un objeto, dejando en manos de las subclases la decisión de que clase concreta instanciar. Es algo complicado explicartelo por este medio pero lo voy a intentar. 

     

    En este gráfico se ve la arquitectura de la aplicación de ejemplo que te pase:

    http://msdn2.microsoft.com/en-us/library/Aa479070.bdasamppet409l(en-us,MSDN.10).gif

     

    En la capa de acceso a datos, se ve una pequeña capita que se llama factory, que esta en los paquetes ProfileDAL, Inventory and Orders Data Access y Messaging. Lo puedes ver en el código fuente del .Net Petshop en el proyecto DALFactory. Este proyecto contiene la funcionalidad necesaria para crear instancias de clases de la capa de acceso a datos acorde con la configuración definida en el archivo Web.Config.  Esto habilta al .Net Petshop a que soporte una variedad de plataformas de base de datos. Asi, si vos necesitas trabajar con Oracle, en la configuración del Web.Config simplemente le decis que vas a trabajar con OracleDAL, o si es el caso, necesitas trabajar con SqlServer, en el Web.Config define que vas a trabajar con SqlServerDAL.

     

    Como en la capa de la logica del negocio, no importa sobre que plataforma de base de datos se va a trabajar, entonces esta capa recibe una interface que es un contrato comun que debe implementar cada clase de la capa de acceso a datos. Las interfaces estan en IDALFactory. Asi, cuando desde la logica del negocio, se invoque una funcionalidad de la capa de acceso a datos, el factory se va encargar de instanciar la subclase acorde a la parametrización del Web.Config, y retornara una interface que sera comun para cualquier proyecto de acceso a Datos (SqlServerDAL, OracleDAL).

     

    Esto hara que sea transparente el cambio de plataforma de base de datos, y que no sea necesario recompilar la solución si existe un requerimiento de cambio de proveedor de base de datos.

     

    Espero, que hallas entendido algo...

     

    Saludos...

     

     

    viernes, 14 de diciembre de 2007 15:08

Todas las respuestas

  •  

    Hola Rodrigo,

     

    Deberias de revisar esta aplicación estandar de ejemplo que esta diseñada para mostrar las mejores prácticas para construir aplicaciones empresariales n-capas en .Net 2.0.

     

    Descarga el código y lee el articulo y si tienes alguna inquietud, me comentas.

     

    http://msdn2.microsoft.com/en-us/library/aa479070.aspx

     

     

    Respecto a la pregunta que hiciste, creo que lo implementaria de la siguiente forma:

     

    La estructura de tablas seria esta:

    FACTURA

     

    numerofactura   -- Llave primaria

    sucursal

    puesto

    tipo

    letra

    fecha

    cliente

    subtotal

    totalfactura

     

    Haria la relación entre Factura y DetalleFactura donde la llave primaria numeroFactura de la tabla Factura viajara a la tabla DetalleFactura y quedara como llave foranea. Para formar una llave única en la tabla DetalleFactura pondria un numero que identifique el detalle de la factura y el numero de la factura como llaves primarias.

     

    DETALLE FACTURA

     

    numero           -- Llave Primaria

    numerofactura -- Llave Primaria, Llave Foranea

    codigoarticulo

    cantidad

    precio

    codiva

     

    A la hora de mapear estas tablas a clases, crearia una clase con solo propiedades (Get y Set) para cada tabla. Por lo tanto, existiria una clase FacturaInfo.cs y otra DetalleFacturaInfo.cs:

     

    La clase DetalleFacturaInfo seria de esta forma:

     

    public class DetalleFacturaInfo

    {

      // Internal member variables
      private string _numero;
      private string _codigoArticulo;
      private int _cantidad;
      private decimal _precio;

      private int _codIva;

     

    public DetalleFacturaInfo(){}

    ...


      // Properties
      public string NumeroFactura {
       get { return _id; }
       set { _id = value; }
      }

     

    //Todas las propiedades que expongan los campos privados definidos en la parte superior de esta clase

     

      public decimal Precio{
       get { return _precio; }
       set { _precio= value; }
      }

     

      public decimal SubTotal {
       get { return _precio* _cantidad; }
      }

    }

     

    y la clase FacturaInfo.cs seria de esta forma:

     

    public class FacturaInfo

    {

      // Internal member variables
      private string _numerofactura;
      private string _sucursal;

      private string _puesto;
      private string _tipo;

      private string _letra;
      private string _fecha;
      private ClienteInfo _cliente;
      private List<DetalleFacturaInfo> _detalleFactura; //Colección de objetos DetalleFactura(Articulos de la factura)

      private decimal _totalFactura;

     

    //Constructor

    public FacturaInfo(){}

    ...


      // Properties
      public string NumeroFactura {
       get { return _id; }
       set { _id = value; }
      }

     

      public List<DetalleFacturaInfo> DetalleFactura{
       get { return _detalleFactura; }
       set { _detalleFactura= value; }
      }

     

    //Todas las propiedades que expongan los campos privados definidos en la parte superior de esta clase

    }

    Para ver esto con mayor claridad, y como se implementaria las otras capas, podes revisar el link que te pase. En este link se ve claramente la arquitectura de como se debe montar las aplicaciones con .Net.

     

    Si tienes alguna duda o inquietud, con gusto la atendere

     

    Saludos... 

     

     

    martes, 11 de diciembre de 2007 18:49
  • Yo en estos temas siempre hago la misma recomendación...

    http://www.lhotka.net/cslanet/

     

    Wink

     

    miércoles, 12 de diciembre de 2007 7:41
  • hola juancho gracias por tu decidacion a mi tema te lo agradezco. me resulto muy util tu ejemplo y a la aplicacion del link ya la baje solo me queda analizarla.

    por ahora te hago otra pregunta , con respecto a los metodos de las clases factura y detalle donde los creo?, en la misma clase de cada una o para trabajar en capas deberia crearlos en otras clases . he visto una aplicacion en capas y las clases entidades solo tienen las propiedades del objeto y dentro de esta clase cuando se quiere usar un metodo se crea un objeto a partir de una clase de la capa de negocio y se utilizan sus metodos, seria algo asi?

     

    gracias 

    miércoles, 12 de diciembre de 2007 12:13
  •  

    Hola Rodrigo,

     

    Si, asi seria. Piensa en los objetos entidades (FacturaInfo.cs y DetalleFacturaInfo.cs) como objetos de transferencia (Transfer Objects), los cuales tu puedes pasar o comunicar entre capas. Es decir, tu vas a poder crear instancias de estos objetos desde la capa de presentación, logica del negocio y acceso a datos. Estos objetos no tendran ningún método, solamente los campos privados, constructores y propiedades.  Desde la capa de lógica del negocio tal como tu lo dijiste, tendras una clase que contenga los servicios u operaciones de estos objectos. Es decir, puedes tener una clase Factura.cs en la capa del negocio que exponga los métodos de InserarFactura, ObtenerFacturas, etc...

     

    Mas o menos, asi quedaria la clase en la lógica del negocio:

     

    public class Factura

    {

              //Recibe como parametro un objeto entidad FacturaInfo

    public void InsertarFactura(FacturaInfo factura)

    {

      ...

    }

     

    public List<FacturaInfo> ObtenerFacturas()

    {

     ...

    }

     

    }

     

    Interesante que revises el patron de diseño de software Factory que tambien lo implementan en la aplicacíón de ejemplo que te pase.

     

    Saludos...

     

    miércoles, 12 de diciembre de 2007 13:39
  • gracias por tu atencion juancho ,,, realmente  te felicito a vos y  a todas las personas del foro que aportan sus conocimientos para ayudar 

     

    me podes decir en que parte del proyecto se encuentra lo del patron del diseño o guiarme un poquito sobre este tema porque veo varios proyectos dentro de la solucion pero no entiendo como ver este tema de patron de diseño

     

     

    miércoles, 12 de diciembre de 2007 16:34
  • Hola Rodrigo,

     

    Que alegria saber que ha sido de gran utilidad este post, eso es lo que uno siempre espera. OK, el factory es un patrón de diseño de software. Define una interfaz para la creación de un objeto, dejando en manos de las subclases la decisión de que clase concreta instanciar. Es algo complicado explicartelo por este medio pero lo voy a intentar. 

     

    En este gráfico se ve la arquitectura de la aplicación de ejemplo que te pase:

    http://msdn2.microsoft.com/en-us/library/Aa479070.bdasamppet409l(en-us,MSDN.10).gif

     

    En la capa de acceso a datos, se ve una pequeña capita que se llama factory, que esta en los paquetes ProfileDAL, Inventory and Orders Data Access y Messaging. Lo puedes ver en el código fuente del .Net Petshop en el proyecto DALFactory. Este proyecto contiene la funcionalidad necesaria para crear instancias de clases de la capa de acceso a datos acorde con la configuración definida en el archivo Web.Config.  Esto habilta al .Net Petshop a que soporte una variedad de plataformas de base de datos. Asi, si vos necesitas trabajar con Oracle, en la configuración del Web.Config simplemente le decis que vas a trabajar con OracleDAL, o si es el caso, necesitas trabajar con SqlServer, en el Web.Config define que vas a trabajar con SqlServerDAL.

     

    Como en la capa de la logica del negocio, no importa sobre que plataforma de base de datos se va a trabajar, entonces esta capa recibe una interface que es un contrato comun que debe implementar cada clase de la capa de acceso a datos. Las interfaces estan en IDALFactory. Asi, cuando desde la logica del negocio, se invoque una funcionalidad de la capa de acceso a datos, el factory se va encargar de instanciar la subclase acorde a la parametrización del Web.Config, y retornara una interface que sera comun para cualquier proyecto de acceso a Datos (SqlServerDAL, OracleDAL).

     

    Esto hara que sea transparente el cambio de plataforma de base de datos, y que no sea necesario recompilar la solución si existe un requerimiento de cambio de proveedor de base de datos.

     

    Espero, que hallas entendido algo...

     

    Saludos...

     

     

    viernes, 14 de diciembre de 2007 15:08
  • gracias  juancho por aclararme el proyecto del petshop, lo voy a revisar siguiendo  tu ayuda y despues te comento

     

    muy amable de tu parte

     

    martes, 18 de diciembre de 2007 17:42