FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
|||
|
|||
Duda - Desarrollo OOP en capas
Buenas compañeros! como están? Abro este hilo debido a que quiero cambiar la forma de trabajar y hacerlo de una manera mas correcta.
Estuve buscando mucho y vi varios post en el foro y en otros lados pero ninguno me aclaró mucho. Actualmente realizo mis trabajos de forma orientada a eventos y muy desordenada, y me gustaría comenzar a desarrollar aplicando la arquitectura en 3 capas, me refiero a Datos, Negocio y Presentación para poder separar la lógica del GUI. Ademas quiero comenzar a desarrollar librerias de clases, para utilizar en futuras aplicaciones, por ejemplo TClientes, TProveedores, TFacturas, TArticulos, etc. Tengo varias dudas al respecto y se las menciono a continuación: 1- Es conveniente crear un Unit para cada clase, es decir crear un Unit para TClientes uno para TProveedores, etc.. y referenciarlos segun mi necesidad? o uno solo con todas las clases? 2- Para un alta por ejemplo de un cliente, quien seria el responsable de hacer el insert en la BBDD? La capa de datos? la de Negocio? El Unit TCliente con un metodo propio de la clase? 3- Cual es el rol de la capa de Negocio? Tenia pensada otra forma de trabajar pero no se si esta bien, esta forma seria: - Crear Units para cada clase por ejemplo TCliente - Cada clase tendra sus datos privados (nombre, apellido, fecha nacimiento,etc...) - Cada clase tendra sus propios metodos get y set para acceder a los datos privados. - Cada clase tendra sus propios metodos para mantener la base de datos(es decir altas bajas modificaciones). Me refiero a crear un metodo insertar que guardara los datos en la base de datos por lo tanto cuando quiera guardar los datos del cliente hare:
y la definicion del metodo seria mas o menos asi:
Es correcto el razonamiento anterior? Un problema que encuentro es al momento de reutilizar la clase TCliente tendre que utilizar el mismo nombre para el TZQuery es decir QClientes. Perdon por tantas preguntas, pero es un tema que no tengo muy claro. Espero puedan ayudarme y desde ya muchas gracias a todos!!! |
#2
|
||||||
|
||||||
Cita:
Cita:
Disponer en ésta las clases necesarias que dan forma justamente, al contexto del negocio. Es la extensión del concepto de Lógica. Toda potencial clase candidata y conceptual que se prevee dentro del contexto bajo estudio puede que sea de utilidad para dar forma al sistema. Cita:
Una clase que no sabe delegar y comunicarse con otra no sirve. Como así también una clase altamente acoplada y relacionada a muchas tampoco sabe delegar. En el medio tienes la respuesta. Cita:
Cita:
No es un pecado hacer lo que sugieres, pero tu diseño tiene un problema de cohesión. Fíjate que ahora la clase no sólo asume la responsabilidades que se han previsto para su contexto sino que ahora debe hacerse cargo de las operaciones sobre la base de datos... Se está perdiendo cohesión. Y otro punto, como dices: acabas atando a tu clase a una tecnología puntual de acceso a base de datos. Precisamente por esto es que se sugiere la presencia de una capa de persistencia. Cita:
Saludos, |
#3
|
||||
|
||||
Bueno, además de la lectura obligada que recomienda Delphius, es necesario poner en práctica los conceptos aprendidos, que pueden llegar a ser muy abstractos cuando ya se tiene un paradigma de programación en la cabeza...
Cita:
En mi poca experiencia personal sobre el tema, DEFINITIVAMENTE SI te recomiendo trabajar una unidad por cada clase, aunque lógicamente habrán ocasiones en que sea necesario definir mas de una clase en la misma unidad. (Generalmente cuando estan muy relacionadas). A manera de ejercicio recomiendo siempre pensar que cada clase se diseña para ser publicada y comercializada de forma separada, como si estuvieras diseñando un componente. El objetivo de esto es llegar a un nivel alto de abstracción e independencia de cada clase. Hago un paréntesis para comentar un detalle en la forma como nombras las clases, aunque no es importante, (y además depende de tus necesidades), tus clase no deberían llamarse TClientes, TProveedores, TFacturas... sino TCliente, TProveedor, TFactura... sencillamente por que eso te lleva a un nivel mas de abstracción. (individual vs. colectivo). No es lo mismo decir LosClientes.Crear, LosClientes.Guardar, que ElCliente.Cargar y ElCliente.Guardar. La lógica y el procesamiento en cada caso es distinto. Aunque vuelvo y repito depdne de lo que estes trabajando. Cita:
Esto es importante ya que si logras independizar la capa de datos de las otras dos, podras pensar en un sistema multiBD o en un sistema que trabaje igual Local que de forma remota. La capa de negocio se debe concentrar en recoger los datos (De la GUI, De un archivo, de la capa de persistencia), procesarlos, validarlos (de acuerdo a unas reglas de negocio) y enviarlos de nuevo a la Capa de presentación o a la de persisntecia según corresponda. Piensa que el dia de mañana ya no vas a trabajar tu sistema en un PC con interfaz Windows, sino que vas a exponer tu aplicación como servicios web... Tu lógica de negocio o deberia cambiar, ni tampoco tu capa de persistencia... estaria mal encontrar en tu capa de negocio algo como:
Por que estarias amarrando tu clase a la forma que estas trabajando.... Además como regla, "las capas internas no deben utilizar (Uses) las capas externas"... Presentación ==Utiliza==> Negocio ==Utiliza==> Persistencia Cita:
Cita:
Por otro lado, te sugeriria que manejaras otra filosofia en cuanto a la forma como ves la clase clientes... Clientes.Insertar(parametros)... está muy ligado a pensar en base de datos.... debes pensar mas en tu negocio y en lo que representa para ti un cliente... Es decir, deberias trabajar algo como:
Separar en capas y trabajar clases independientes (tipo componente) puede representar un trabajo dispendioso... para algunos innecesario o redundante, pero tiene muchas ventajas a la hora de moverte entre arquitecturas.. En mi experiencia reciente, tuve la oportunidad de comprobar sus beneficios.... Yo tenia una aplciación Cliente servidor que utilizaba una clase TComprobanteContable. esta clase a su vez utilizaba una clase TEjecutorSQL que se encargaba de hacer el "trabajo sucio" en la base de datos... entonces mi clase funcionaba algo asi:
Mi ejecutorSQL es un componente que previamente he conectado a una base de datos (PostgreSQL, Interbase, Oracle o SQL server)... ¿como lo hace? pues a mi clase TComprobanteContable no le importa... solo le importa que cumpla con su parte... Bueno, siguiendo con la historia... cuando quise migrar a la nube mi aplicación con DataSnap, pues no tuve que cambiar mi GUI, ni mi TComprobanteContable, ni mi ejecutor... solo tuve que crear unas clases TComprobanteContableRemoto, TEjecutorSQLRemoto que utilizaban los Mismos Metodos de las clases definidas inicialmente, es decir algo como:
Espero haber sido claro y haberte ayudado en algo... |
#4
|
||||
|
||||
Impresionante Gatosoft,
Que bien has ampliado mis palabras. Con eso creería que casi todas las dudas ya se disiparían. Yo quisiera aclarar que al momento de leer el libro que recomendé no se lo hiciera de una sola pasada. Yo estimo que mínimo se lo va leer unas 10 veces. Hay que hacer una pequeña observación sobre dicho material bibliográfico: se asume que hay una preparación previa sobre los conceptos de POO y algo de UML. No está pensado para enseñar POO pero si está muy enfocado para aportar una perspectiva muy analista sobre dicho paradigma. Su aporte al A/DOO es riquísimo. Para UML, que recontra recomiendo su uso, lo más confiable y completo es leer UML 1.5 (mínimo... en lo posible 2.0 y si desean pueden ir a 2.2; la 2.5 todavía está en borrador que yo sepa). Léase el libro de los 3 gurus; que es el más en detalle y completo ¡y oficial!. Otro de los muy citados es UML Distilled Recuerdo que en otro hilo se ha aportado biografía sobre el tema. Saludos, |
#5
|
|||
|
|||
Muchas gracias por responder Delphius y gatosoft, de verdad me sirvieron de mucho las explicaciones que me dieron. De verdad valoro su dedicacion para responder de forma tan completa y clara. Da gusto discutir estos temas con gente que sabe. Lo unico que me hace falta es comenzar con practica. UML y patrones lo lei ya dos veces y conozco de patrones pero nunca supe llevarlos a la practica. Nuevamente gracias!
|
#6
|
||||
|
||||
Cita:
Para abordar los patrones se requiere además del complemento del UML por lo que es necesario tener las nociones básicas de ésto. Las cosas se te van a ir forjando en la medida en que lo vayas volcando en la práctica. Nadie dijo que sea fácil. Como consejo final: ¡tampoco hay que dejarse contagiar de la patronitis! Craig en su libro le dedica unas palabras a esa enfermedad y quien escribe estas líneas también te lo advierte ¡por experiencia propia! Saludos, |
#7
|
|||
|
|||
DataSnap
Hola Gatosoft
Cuando leemos estas disertaciones uno respira profundo para tratar de entender, sobre todo aquellos que no tenemos formacion en informatica, si no que solo aprendimos a programar hace ya varios anos. He querido utilizar DataSnap , sobre todo la parte de los callback , es posible que nos hablas sobre tu experiencia con datasnap ? |
#8
|
||||
|
||||
Amigo ASAPLTDA, la verdad mi experiencia con DataSnap es bastante reciente, y todo gracias a que me vi obligado a estudiar sobre el tema debido a un proyecto nuevo que estoy trabajando para la empresa que acabé de formar...
En lo que si considero que tengo bastante experiencia es en POO, y creo que eso me ha facilitado comprender y adaptarme al concepto de DataSnap... Aunque uno nunca termina de aprender y siempre que me paso por el club para ver las respuestas de los verdaderos "maestros" que frecuentan este sitio, encuentro cosas que me aún me sorprenden de Delphi Pues como decía, en estos meses de lucha he aprendido bastante y precisamente estoy preparando un blog o videoblog para exponer lo poco que conozco sobre ciertos temas. Creo que después de tantos años...ya es hora...! De cualquier forma estoy atento a cualquier información que quieras sobre el tema... es mas si me paso por cali en estas vacaciones podríamos vernos y hablar de negocios (de empresa a empresa)... Por ahora, si aún no te has pasado por ahí, te recomiendo y les recomiendo a todos la serie de videos Delphi Labs, de Pawel Glowacki, Son muy buenos para iniciarse en DataSanap. Un saludo |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
desarrollo WEB vs. desarrollo tradicional | _iceman | Debates | 42 | 28-02-2013 17:36:00 |
Duda sobre OOP y capas | AzidRain | OOP | 4 | 04-08-2007 00:25:35 |
aplicacion 3 capas en c# | cuscus | .NET | 2 | 15-11-2005 21:06:57 |
Clipper en 3 Capas ???? | AGAG4 | Providers | 3 | 30-06-2005 19:03:17 |
Dibujando en capas | blueicaro | Gráficos | 1 | 26-04-2005 09:46:02 |
|