Continuando con los patrones de la capa de negocio llega el turno de Domain Model
Patrón Domain Model
Al contrario que el patrón Transaction Script, la idea ahora es poder soportar lógica de negocio muy compleja por medio de Clases (si ahora solo puede ser POO).
El patrón Domain Model, nos dice que ahora habrá que modelar el negocio y bajarlo a nivel de entidades, que en algún momento se traducirán a clases.
En muchas ocasiones se confunde el Modelo de Dominio con el Modelo Entidad - Relación (Diagrama de la base de datos), cuando lo cierto es que estos dos modelos son muy diferentes, ya que el modelo de dominio no solo maneja datos, si no también procesos y algunos expertos dicen que tampoco debe permitir herencia.
19 de noviembre de 2010
Capa de Negocio (Parte 3): Table Module
Patrón Table Module
Es último patrón y no por eso el menos importante.
Este patrón tiene su base en el modelo E-R de una base de datos, ya que ahora las clases contendías en la capa de negocio son una representación de las tablas de la base de datos.
Es decir que ahora habrá una Clase que se encargará de administrar todo el comportamiento y lo datos que una tabla en particular.
La diferencia principal entre el Domain Model y el Table Module es que, mientras que con el patrón Domain Model manejas un objeto por cada Cuenta Bancaria (retomando el ejemplo anterior) con Table Module, tendrás un solo objeto para manejar todas las Cuentas Bancarias y ahora si tendrás una clase llamada "OperacionBancaria".
Es último patrón y no por eso el menos importante.
Este patrón tiene su base en el modelo E-R de una base de datos, ya que ahora las clases contendías en la capa de negocio son una representación de las tablas de la base de datos.
Es decir que ahora habrá una Clase que se encargará de administrar todo el comportamiento y lo datos que una tabla en particular.
La diferencia principal entre el Domain Model y el Table Module es que, mientras que con el patrón Domain Model manejas un objeto por cada Cuenta Bancaria (retomando el ejemplo anterior) con Table Module, tendrás un solo objeto para manejar todas las Cuentas Bancarias y ahora si tendrás una clase llamada "OperacionBancaria".
ORM (Object Relation Mapping) Parte 1
¿Que es ORM?
Al surgir la programación orientada a objetos, todo pareció ser alegría hasta el momento de tener que enfrentarse con un dilema, "Bases de datos"
Cuando la POO comenzó a tener un gran empuje, las personas comenzaron a preguntarse porque no tener también una Base de Datos Orientada a Objetos (BDOO), así que algunos comenzaron a investigar al respecto, pero... cual fue el problema.
Las Bases de Datos Relacionales dominaban el mercado, había compañías muy sólidas respaldaban sus productos, el lenjuage SQL ya era un estándar que todos conocían y las BDOO apenas estaban en plena concepción, dado que lo mas importante para las compañías es su información (Datos), no iban a apostar por una nueva herramienta en pleno desarrollo y dejar a un lado las ya maduras Bases de Datos Relacionales. Así que el paradigma de las BDOO se fue rezagando hasta quedar prácticamente en el olvido actualmente.
En el mundo de caramelo de la POO, trabajar con una BDOO sería exelente por no decir magnifico, ya que la explotación de los datos sería mediante Objetos, es decir, se lanzaría una petición a la BD y esta en lugar de regresar un conjunto de datos como lo hace una BDR, regresaria un conjunto de objetos, representando una Entidad muy particular, así todo se manejaría a nivel de Objetos y no de datos.
Al surgir la programación orientada a objetos, todo pareció ser alegría hasta el momento de tener que enfrentarse con un dilema, "Bases de datos"
Cuando la POO comenzó a tener un gran empuje, las personas comenzaron a preguntarse porque no tener también una Base de Datos Orientada a Objetos (BDOO), así que algunos comenzaron a investigar al respecto, pero... cual fue el problema.
Las Bases de Datos Relacionales dominaban el mercado, había compañías muy sólidas respaldaban sus productos, el lenjuage SQL ya era un estándar que todos conocían y las BDOO apenas estaban en plena concepción, dado que lo mas importante para las compañías es su información (Datos), no iban a apostar por una nueva herramienta en pleno desarrollo y dejar a un lado las ya maduras Bases de Datos Relacionales. Así que el paradigma de las BDOO se fue rezagando hasta quedar prácticamente en el olvido actualmente.
En el mundo de caramelo de la POO, trabajar con una BDOO sería exelente por no decir magnifico, ya que la explotación de los datos sería mediante Objetos, es decir, se lanzaría una petición a la BD y esta en lugar de regresar un conjunto de datos como lo hace una BDR, regresaria un conjunto de objetos, representando una Entidad muy particular, así todo se manejaría a nivel de Objetos y no de datos.
5 de noviembre de 2010
Patrón DAO (Data Access Object)
Es un patrón canonizado por SUN, el cual se encuentra dentro de la definición de los J2EE Patterns.
Pero... para empezar a hablar sobre este patrón, primero deberemos entender que son los Tansfer Object (TO)
El origen de este patrón surge por el uso de EJB; Los EJB son una instancia de clase remota a la cual se accede por mecanismos RMI.
¿Que, qué es un EJB?
En otro momento entraré en detalles mas técnicos, por ahora lo explicaré muy someramente.
Basado en un patrón Domain Model, se identifican todas las entidades de negocio y se transforman a clases, de las cuales se generan instancias. Las clases contienen cierta lógica del negocio o dominio, es decir, son como objetos especializados en resolver algún tema particular.
Pero... ¿qué pasa si hay muchos sistemas que necesitan utilizar estas clases?. Es entonces cuando entran en escena los EJB. Lo que se le ocurrió a SUN, fue generar un contenedor de instancias de las entidades de negocio, una cajita donde siempre estuvieran disponibles los Objetos, lo cual también significa, que deberían estar aislados del resto de aplicaciones o por lo menos separados del resto.
Pero... para empezar a hablar sobre este patrón, primero deberemos entender que son los Tansfer Object (TO)
Transfer Object
El origen de este patrón surge por el uso de EJB; Los EJB son una instancia de clase remota a la cual se accede por mecanismos RMI.
¿Que, qué es un EJB?
En otro momento entraré en detalles mas técnicos, por ahora lo explicaré muy someramente.
Basado en un patrón Domain Model, se identifican todas las entidades de negocio y se transforman a clases, de las cuales se generan instancias. Las clases contienen cierta lógica del negocio o dominio, es decir, son como objetos especializados en resolver algún tema particular.
Pero... ¿qué pasa si hay muchos sistemas que necesitan utilizar estas clases?. Es entonces cuando entran en escena los EJB. Lo que se le ocurrió a SUN, fue generar un contenedor de instancias de las entidades de negocio, una cajita donde siempre estuvieran disponibles los Objetos, lo cual también significa, que deberían estar aislados del resto de aplicaciones o por lo menos separados del resto.
Suscribirse a:
Entradas (Atom)