Comments for Kepasaka Blog http://kepasaka.com/blog "Tecnología, Informática y mucho más..." Wed, 31 Mar 2010 15:05:17 +0000 hourly 1 http://wordpress.org/?v=3.0 Comment on ¿Llaves naturales (Opinión)? by Nando http://kepasaka.com/blog/?p=295&cpage=1#comment-1273 Nando Wed, 31 Mar 2010 15:05:17 +0000 http://kepasaka.com/blog/?p=295#comment-1273 De hecho, nosotros hemos trabajado bastante en eso, para la identificación de pacientes, llegando a la conclusión de que la mejor opción son las llaves naturales. Y para mi la principal razón es mantener el control (como dice Ernesto), así validar que la misma base de datos no permita tener dos registros de personas virtualmente diferentes, que sean la misma... Hay algunos aspectos que nos hicieron analizar la idea de las llaves subrogadas, por ejemplo para una funcionalidad nuestra: modificar numero de identificación. Entonces pensé en una tabla intermedia donde se fusionaran los numeros de identificacion, tanto "el viejo" como "el nuevo", y así solo modificar el número de identificación en dicha tabla de asocie. Pero conociendo las experiencias de otros compañeros, esto ha servido para la duplicación de registros, desnormalización de la base de datos, además complicaría severamente una minería de datos, por ejemplo. De hecho, nosotros hemos trabajado bastante en eso, para la identificación de pacientes, llegando a la conclusión de que la mejor opción son las llaves naturales. Y para mi la principal razón es mantener el control (como dice Ernesto), así validar que la misma base de datos no permita tener dos registros de personas virtualmente diferentes, que sean la misma…
Hay algunos aspectos que nos hicieron analizar la idea de las llaves subrogadas, por ejemplo para una funcionalidad nuestra: modificar numero de identificación. Entonces pensé en una tabla intermedia donde se fusionaran los numeros de identificacion, tanto “el viejo” como “el nuevo”, y así solo modificar el número de identificación en dicha tabla de asocie. Pero conociendo las experiencias de otros compañeros, esto ha servido para la duplicación de registros, desnormalización de la base de datos, además complicaría severamente una minería de datos, por ejemplo.

]]> Comment on Value Objects y DataTransfer Objects by Neto http://kepasaka.com/blog/?p=302&cpage=1#comment-1235 Neto Mon, 08 Mar 2010 18:06:53 +0000 http://kepasaka.com/blog/?p=302#comment-1235 Si creo que lo que pasa o donde ponen la diferencia es que los VO's son tipos que contienen nada mas que valor y cuya identidad se define por esos valores. La confusión está, incluso en wikipedia los definen como si fueran lo mismo. Yo he visto que el término value object lo extienden al punto que no solo se refiere a tipos primitivos sino a tipos que solo tienen tipos primitivos. POCO's que no contienen valores por referencia. Generalmente estos tipos que no crean una estructura sino que son hasta cierto punto una aglomeración de propiedades para transportar datos los he visto usados para cumplir tareas especificas como cargar un grid o cosas así. Por eso el enredo de términos. A fin de cuentas todos estos los he visto implementados como POJOs (o POCOs) que no tienen implementación de ningún tipo porque de alguna manera en la simplicidad es que está el valor de estos objetos. Se cargan usando patrones que les mantengan cierta independencia. Creo que el problema es que siempre hay mucho apego a los términos y mucha gente influyente quiere adueñarse de x concepto y todos le ponen diferente nombre a la misma cosa con mínimas variantes, o inclusive nombran prácticas comunes para adueñarselas y de ahí nacen las confusiones. Si creo que lo que pasa o donde ponen la diferencia es que los VO’s son tipos que contienen nada mas que valor y cuya identidad se define por esos valores. La confusión está, incluso en wikipedia los definen como si fueran lo mismo. Yo he visto que el término value object lo extienden al punto que no solo se refiere a tipos primitivos sino a tipos que solo tienen tipos primitivos. POCO’s que no contienen valores por referencia.
Generalmente estos tipos que no crean una estructura sino que son hasta cierto punto una aglomeración de propiedades para transportar datos los he visto usados para cumplir tareas especificas como cargar un grid o cosas así. Por eso el enredo de términos.
A fin de cuentas todos estos los he visto implementados como POJOs (o POCOs) que no tienen implementación de ningún tipo porque de alguna manera en la simplicidad es que está el valor de estos objetos. Se cargan usando patrones que les mantengan cierta independencia.

Creo que el problema es que siempre hay mucho apego a los términos y mucha gente influyente quiere adueñarse de x concepto y todos le ponen diferente nombre a la misma cosa con mínimas variantes, o inclusive nombran prácticas comunes para adueñarselas y de ahí nacen las confusiones.

]]> Comment on Value Objects y DataTransfer Objects by David Chaverri http://kepasaka.com/blog/?p=302&cpage=1#comment-1229 David Chaverri Thu, 04 Mar 2010 21:22:41 +0000 http://kepasaka.com/blog/?p=302#comment-1229 Usted esta hablando de un entity de una manera muy subjetiva, en cuanto a que significa un entity para usted, un Business Entity tal como yo los conozco solo representan la estructura del objeto el hecho de como implemente usted la relacion con otro objeto, cuando lo cargue y demas no tiene que ver con el concepto de entity en si, si no con COMO lo implemente usted, yo no acostumbro tener la implementacion en el Business Entity siempre existe un handler/manager como quiera llamarle que me brinda el SERVICIO de obtener el o los objetos relacionados, que ud los llame dentro del entity, que haga un lazy load, etc etc etc, es implementacion especifica, pero el concepto de Entity, DTO es un objeto que simplemente tiene la estructura del objeto, inclusive podria yo decir que es un objeto 100 serializable, y que no contiene metodos, si lo quiere ver de otra forma. Es la abstraccion pura del objeto La clase y sus atributos. Por eso puse el ejemplo de WCF o bien Web Services, si un servicio utiliza una estructura como la famosa clase Persona, esta se debe conocer por el cliente tambien, y el WS en si es el que contiene la implementacion, por eso el ejemplo del DtaContract Usted esta hablando de un entity de una manera muy subjetiva, en cuanto a que significa un entity para usted, un Business Entity tal como yo los conozco solo representan la estructura del objeto el hecho de como implemente usted la relacion con otro objeto, cuando lo cargue y demas no tiene que ver con el concepto de entity en si, si no con COMO lo implemente usted, yo no acostumbro tener la implementacion en el Business Entity siempre existe un handler/manager como quiera llamarle que me brinda el SERVICIO de obtener el o los objetos relacionados, que ud los llame dentro del entity, que haga un lazy load, etc etc etc, es implementacion especifica, pero el concepto de Entity, DTO es un objeto que simplemente tiene la estructura del objeto, inclusive podria yo decir que es un objeto 100 serializable, y que no contiene metodos, si lo quiere ver de otra forma. Es la abstraccion pura del objeto La clase y sus atributos. Por eso puse el ejemplo de WCF o bien Web Services, si un servicio utiliza una estructura como la famosa clase Persona, esta se debe conocer por el cliente tambien, y el WS en si es el que contiene la implementacion, por eso el ejemplo del DtaContract

]]> Comment on Value Objects y DataTransfer Objects by El_Hijo http://kepasaka.com/blog/?p=302&cpage=1#comment-1226 El_Hijo Wed, 03 Mar 2010 20:15:38 +0000 http://kepasaka.com/blog/?p=302#comment-1226 Si es cierto David Chaverri tiene toda la razón en lo que es un value Object por decirlo así y aunque suene redundante es un objeto que va atado a un valor o representa un valor, estos comportamientos también los podemos ver en los tipos enumerados donde cada uno representa un valor no importando la plataforma en la que estén, sea esta Java o .Net, o los Integers que tienen un rango definido pero solo pueden tener valores integres y cada variable o instancia de un integer es inmutable lo que lo hace ser un objeto que corresponde con el valor que almacena y así un Value Object, en el caso de la confusión es que en Java el termino de Value Object como el de DataTransfer Object se emplea por igual siempre que se crea un Objeto de Transferencia de Datos se le pone el nombre de Value Object lo cual no es correcto por que no es un Objeto que represente un Valor como tal si no que sirve para transferir información. En cuanto a la comparación de entities no estoy de acuerdo debido a que una entidad tiene comportamiento he implementación impuesta por un Framework (implementaciones como algoritmos de cache, lazy loading, etc…) o cualquier otra cosa que utilicemos y se supone que los DataTransfer Object se utilizan para transferir objetos entre capas sin ninguna implementación. ¿Veámoslo así si una entidad Persona tiene una relación con una Entidad Direccion como haría la entidad Persona para cargar todas las direcciones que le pertenezcan a esa entidad Direccion sin tener implementación? Si es cierto David Chaverri tiene toda la razón en lo que es un value Object por decirlo así y aunque suene redundante es un objeto que va atado a un valor o representa un valor, estos comportamientos también los podemos ver en los tipos enumerados donde cada uno representa un valor no importando la plataforma en la que estén, sea esta Java o .Net, o los Integers que tienen un rango definido pero solo pueden tener valores integres y cada variable o instancia de un integer es inmutable lo que lo hace ser un objeto que corresponde con el valor que almacena y así un Value Object, en el caso de la confusión es que en Java el termino de Value Object como el de DataTransfer Object se emplea por igual siempre que se crea un Objeto de Transferencia de Datos se le pone el nombre de Value Object lo cual no es correcto por que no es un Objeto que represente un Valor como tal si no que sirve para transferir información.

En cuanto a la comparación de entities no estoy de acuerdo debido a que una entidad tiene comportamiento he implementación impuesta por un Framework (implementaciones como algoritmos de cache, lazy loading, etc…) o cualquier otra cosa que utilicemos y se supone que los DataTransfer Object se utilizan para transferir objetos entre capas sin ninguna implementación. ¿Veámoslo así si una entidad Persona tiene una relación con una Entidad Direccion como haría la entidad Persona para cargar todas las direcciones que le pertenezcan a esa entidad Direccion sin tener implementación?

]]> Comment on Value Objects y DataTransfer Objects by David Chaverri S. http://kepasaka.com/blog/?p=302&cpage=1#comment-1225 David Chaverri S. Tue, 02 Mar 2010 22:05:35 +0000 http://kepasaka.com/blog/?p=302#comment-1225 Di mae la verdad no se que tenga que ver uno con el otro ... Un value object es un mae primitivo, un NO reference object por decirlo asi, un int por ejemplo, lo que ya todos sabemos que es un value type, un Data Transfer Object diria yo es mas un concepto, en el sentido de que es una estructura de datos para pasar de una capa a otra, por ejemplo tengo un objeto persona (sea una clase o un struct en .net) ese objeto tiene nombre y cedula, la idea de un DTO (hasta donde yo he visto) es que esa estructura de datos pueda ser comprendida por cualquiera de las capas, desde el accesso a datos, hasta el UI, donde cualquier de ellos puede consumirlos, estos objetos la idea es que no contengan implementacion, lo que se conoce como Entities por ejemplo, algo muy comun en arquitecturas SOA, por ejemplo en WCF el DataContract viene siendo un DTO. Saludos !!! Di mae la verdad no se que tenga que ver uno con el otro …

Un value object es un mae primitivo, un NO reference object por decirlo asi, un int por ejemplo, lo que ya todos sabemos que es un value type, un Data Transfer Object diria yo es mas un concepto, en el sentido de que es una estructura de datos para pasar de una capa a otra, por ejemplo tengo un objeto persona (sea una clase o un struct en .net) ese objeto tiene nombre y cedula, la idea de un DTO (hasta donde yo he visto) es que esa estructura de datos pueda ser comprendida por cualquiera de las capas, desde el accesso a datos, hasta el UI, donde cualquier de ellos puede consumirlos, estos objetos la idea es que no contengan implementacion, lo que se conoce como Entities por ejemplo, algo muy comun en arquitecturas SOA, por ejemplo en WCF el DataContract viene siendo un DTO.

Saludos !!!

]]> Comment on Value Objects y DataTransfer Objects by David http://kepasaka.com/blog/?p=302&cpage=1#comment-1224 David Mon, 01 Mar 2010 15:41:57 +0000 http://kepasaka.com/blog/?p=302#comment-1224 Pues segun lo que leo en las definiciones yo diria que la principal diferencia se da en que los data transfer estan hechos con la idea de que sean transferidos. jeje un poco obvio Pues segun lo que leo en las definiciones yo diria que la principal diferencia se da en que los data transfer estan hechos con la idea de que sean transferidos.
jeje un poco obvio

]]> Comment on Subversion el proyecto de código libre se mueve a la ASF by El_Hijo http://kepasaka.com/blog/?p=277&cpage=1#comment-1221 El_Hijo Sat, 27 Feb 2010 06:00:19 +0000 http://kepasaka.com/blog/?p=277#comment-1221 Claro es excelente y también es una herramienta muy facil de instalar y de aprender, en el trabajo en el que estoy actualmente utilizamos clear case pero es demasiado engorroso y dificil de usar en cosas que Subversion de verdad lo hace ver como un juego de niños. Claro es excelente y también es una herramienta muy facil de instalar y de aprender, en el trabajo en el que estoy actualmente utilizamos clear case pero es demasiado engorroso y dificil de usar en cosas que Subversion de verdad lo hace ver como un juego de niños.

]]> Comment on Subversion el proyecto de código libre se mueve a la ASF by Neto http://kepasaka.com/blog/?p=277&cpage=1#comment-1217 Neto Fri, 26 Feb 2010 22:30:59 +0000 http://kepasaka.com/blog/?p=277#comment-1217 Lo usamos donde trabajo, y en el trabajo anterior. Y en el anterior. He usado algunos otros pero si tuviera una empresa propia tambien lo usaría, es una excelente herramienta. Lo usamos donde trabajo, y en el trabajo anterior. Y en el anterior. He usado algunos otros pero si tuviera una empresa propia tambien lo usaría, es una excelente herramienta.

]]> Comment on ¿Llaves naturales (Opinión)? by jonathanjhosue http://kepasaka.com/blog/?p=295&cpage=1#comment-1202 jonathanjhosue Thu, 18 Feb 2010 04:32:48 +0000 http://kepasaka.com/blog/?p=295#comment-1202 Yo prefiero las artificiales hechas de algún metal no ferroso o alguna aleación como el acero o bronce. A mi no me desagradan del todo ya que nos ahorramos campos, obtenemos el valor de inmediato lo que lleva a no hacer un join o where (combinaciones,multiplicaciones de datos) para ciertas consultas. En todo caso si estos tipos de campo ameritan para ser usado como clave primaria generalmente requiere unicidad e indenxación y serán los utilizado objetivamente para realizar las búsquedas. Esto permite también tener tablas más "lógicas" y menos computacionales que para un mejor amarre con el mundo orientado a objetos al ser más naturales, donde las relaciones se dan (o deberían de dar a nivel de objetos y no de ligues). La pregunta es que hacen esos campos en la tabla para que nos sirven todo depende de las circunstancias; también esta el caso de los ids autogenerados extra para las tablas con función de "intermedias" o las bases desnormalizadas. Es relativo. Hay dos puntos en los que si se presentan posibles disconformidades: en el caso de la privacidad cuando un campo no debería de ser "visto" desde otras tablas y la otra por motivos de posibles modificaciones a ese campo clave (aunque esto no es nada del otro mundo para los SGBD modernos y bases de datos bien relacionadas que lo resuelven fácilmente pero algo lento para grandes volúmenes de datos). Nota: Cuando vienen con llavero son más tuanis. Yo prefiero las artificiales hechas de algún metal no ferroso o alguna aleación como el acero o bronce.

A mi no me desagradan del todo ya que nos ahorramos campos, obtenemos el valor de inmediato lo que lleva a no hacer un join o where (combinaciones,multiplicaciones de datos) para ciertas consultas. En todo caso si estos tipos de campo ameritan para ser usado como clave primaria generalmente requiere unicidad e indenxación y serán los utilizado objetivamente para realizar las búsquedas.
Esto permite también tener tablas más “lógicas” y menos computacionales que para un mejor amarre con el mundo orientado a objetos al ser más naturales, donde las relaciones se dan (o deberían de dar a nivel de objetos y no de ligues).
La pregunta es que hacen esos campos en la tabla para que nos sirven todo depende de las circunstancias; también esta el caso de los ids autogenerados extra para las tablas con función de “intermedias” o las bases desnormalizadas. Es relativo.

Hay dos puntos en los que si se presentan posibles disconformidades: en el caso de la privacidad cuando un campo no debería de ser “visto” desde otras tablas y la otra por motivos de posibles modificaciones a ese campo clave (aunque esto no es nada del otro mundo para los SGBD modernos y bases de datos bien relacionadas que lo resuelven fácilmente pero algo lento para grandes volúmenes de datos).

Nota: Cuando vienen con llavero son más tuanis.

]]> Comment on ¿Llaves naturales (Opinión)? by El_Hijo http://kepasaka.com/blog/?p=295&cpage=1#comment-1201 El_Hijo Thu, 18 Feb 2010 04:27:49 +0000 http://kepasaka.com/blog/?p=295#comment-1201 Si yo también prefiero utilizar las llaves surrogadas debido a que si estas no se usan pueden causar muchos problemas como Neto ya lo dijo. Tales como datos flotando por quien sabe cuantas tablas ademas de que si existe la oportunidad de hacer un cambio en la llave como hacer el campo más grande este puede requerir que se modifiquen todas las tablas y no solo la principal tabla o tabla que contiene la llave primaria . Gracias por responder. Si yo también prefiero utilizar las llaves surrogadas debido a que si estas no se usan pueden causar muchos problemas como Neto ya lo dijo. Tales como datos flotando por quien sabe cuantas tablas ademas de que si existe la oportunidad de hacer un cambio en la llave como hacer el campo más grande este puede requerir que se modifiquen todas las tablas y no solo la principal tabla o tabla que contiene la llave primaria .

Gracias por responder.

]]>