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.
27 de octubre de 2010
Patrón Singleton
Cuando escribí el artículo Desarrollo en capas, un amigo me comento que de alguna manera debería de explicar que es el patrón Singleton.
Bien su suplica se ha hecho realidad y para ejemplificar utilizaré Java
En realidad este patrón es muy simple. La idea básica de este patrón es que solo pueda existir una instancia de una clase en la aplicación.
El primer paso para conseguir este patrón es bloquear la forma de generar instancias de la clase, esto se hace simplemente privatizando el constructor de la clase
Bien su suplica se ha hecho realidad y para ejemplificar utilizaré Java
En realidad este patrón es muy simple. La idea básica de este patrón es que solo pueda existir una instancia de una clase en la aplicación.
El primer paso para conseguir este patrón es bloquear la forma de generar instancias de la clase, esto se hace simplemente privatizando el constructor de la clase
12 de octubre de 2010
Capa de Negocio (Parte 1): Transaction Script
Edición: Por sugerencia de varios amigos, he decidido separar este articulo por tema, al final se encuentran las ligas hacia los otros patrones
Recuerdo perfectamente que entre las capas que más trabajo me costo entender como funcionaban y como utilizar fue la capa de negocio y es que termina siendo la ultima que descubres y la última que entiendes como usar y programar, por ello decidí dar un pequeño salto en el orden de las capas para adentrarnos en este pequeño mundito. No quiero decir que no habrá articulo sobre la capa de vista, ¡por su puesto que lo habrá!, solo quise explicar de una vez por todas, lo que mas trabajo me costo entender.
La capa de negocio puede ser manejada de varias formas y en este contexto encontramos principalmente 3 contrincantes, el patrón Transaction Script, el patrón Domain Model y el patrón Table Module.
La conclusión a la cual quiero llegar al final, no es decir cual es mejor o peor, ya que los 3 tienen sus pros y contras; la idea es dar un panorama y porque no, un par de consejos del ¿como? y el ¿cuando? utilizar uno u otro y que al final te sea mas simple tomar una decisión de que patrón(es) te conviene(n) usar mas.
Ahora, vamos a echarle un ojo a los participantes para tener un lugar en la capa de negocio.
La idea básica de este patrón se basa en las rutinas.
Recuerdo perfectamente que entre las capas que más trabajo me costo entender como funcionaban y como utilizar fue la capa de negocio y es que termina siendo la ultima que descubres y la última que entiendes como usar y programar, por ello decidí dar un pequeño salto en el orden de las capas para adentrarnos en este pequeño mundito. No quiero decir que no habrá articulo sobre la capa de vista, ¡por su puesto que lo habrá!, solo quise explicar de una vez por todas, lo que mas trabajo me costo entender.
La capa de negocio puede ser manejada de varias formas y en este contexto encontramos principalmente 3 contrincantes, el patrón Transaction Script, el patrón Domain Model y el patrón Table Module.
La conclusión a la cual quiero llegar al final, no es decir cual es mejor o peor, ya que los 3 tienen sus pros y contras; la idea es dar un panorama y porque no, un par de consejos del ¿como? y el ¿cuando? utilizar uno u otro y que al final te sea mas simple tomar una decisión de que patrón(es) te conviene(n) usar mas.
Ahora, vamos a echarle un ojo a los participantes para tener un lugar en la capa de negocio.
Patrón Transaction Script
La idea básica de este patrón se basa en las rutinas.
9 de octubre de 2010
Desarrollando en Capas
Hace algún tiempo llegue a trabajar a una empresa donde tenían ya algunos sistemas implementados, la empresa tenía la necesidad de añadir funcionalidad a dichos sistemas, comencé a revisarlos y me di cuenta de algo, no existía la capa de negocio (Domain o Business como la quieran llamar), me pregunte muchas veces el porque sin llegar a una respuesta, tenían 2 capas híbridas(porque no eran ni uno ni lo otro), una para la vista y una para acceso a datos, pero, las reglas del negocio estaban mezcladas entre la vista y el acceso a datos, lo cual significa que una nueva regla de negocio o una modificación involucraba mover por todos lados sin tener la certeza que funcionara, así que pensé en escribir algo sobre el como, el porque, el cuando y el donde, yo usaría las 3 capas convencionales (Presentación, Negocio y Acceso a datos).
Suscribirse a:
Entradas (Atom)