[[Delphius]]

Empezado por agustinbus

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?

Depende de las necesidades y el diseño que tu consideres oportuno. Pero un primer criterio a considerar es el acoplamiento. Habrá situaciones que ameriten disponer varias clases en una misma unidad, y habrá otras en los que una clase por unidad.

Empezado por agustinbus

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?

Desde el pensamiento basado en el patrón Capas (Layers) y de los buenos principios quien asume la responsabilidad de materializar un objeto es la capa de persistencia.

Empezado por agustinbus

3- Cual es el rol de la capa de Negocio?

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.

Empezado por agustinbus

Tenia pensada otra forma de trabajar pero no se si esta bien, esta forma seria:

- Crear Units para cada clase por ejemplo TCliente

Ya he dicho que es una cuestión de diseño y necesidades, y de un adecuado nivel de acoplamiento.
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.

Empezado por agustinbus

- 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.

Este... creo que es requisito indispensable para que se mantenga el concepto detrás del paradigma OO. Se da por entendido que es así

Empezado por agustinbus

- 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:

Código Delphi [-]
cliente.Insertar(nombre,apellido,...);

y la definicion del metodo seria mas o menos asi:

Código Delphi [-]
cliente.Insertar(nombre,apellido,...);
begin
  QClientes.Close;
  QClientes.SQL.Clear; 
  QClientes.SQL.Add('INSERT INTO Clientes (NOMBRE, APELLIDO,...) values (:nom, :ape...)');
  QClientes.ParamByName('nom').Value := nombre;
  QClientes.ParamByName('ape').Value := apellido;
  QClientes.ExecSQL;
end;

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.

He dicho que formalmente la responsabilidad de material un objeto desde y hacia la base de datos pasa por una capa de persistencia.
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.

Empezado por agustinbus

Perdon por tantas preguntas, pero es un tema que no tengo muy claro.
Espero puedan ayudarme y desde ya muchas gracias a todos!!!

Existen en el mercado algunos frameworks de persistencia. Podrías examinarlos. Aunque yo primero te sugeriría que te familiarices más con el paradigma OO, los patrones de diseño y el A/DOO. Lectura casi obligada que te sacará más que unas cuantas dudas: UML y Patrones y una Introducción al Análisis y Diseño Orientado a Objetos y al Proceso Unificado de Craig Larman.

Saludos,