capa de negocios

rafael wrote:

Bueno esta una pregunta conceptual, estuve leyendo la guia de desarrollo
de aplicaciones microsoft y cita la capa de logica de negocios, y en el
ejemplo hay una clase,con una funcion Grabar, cuya función (valga la
redundacia) es
realizar la transaccion. Hasta ahi , muy feliz con el ejemplo, :) pero
luego me asalta una duda, en el ejemplo en esa clase de negocio no hay un
metodo,funcion,etc listar o algo similar para devolver todos los
registros de la tabla, entonces , este metodo debe implementarse en esta
clase de negocio, manteniendo el criterio de visibilidad de las capas(pero
creando una funcion que solo devuelve el mismo objeto de datos sin hace
nada mas), o en el formulario debe llamarse al objeto de datos para
hacerlo mucho mas rapido.

Yo lo hago asà­:

Por un lado tengo una clase de acceso a datos, la cual le de un fichero de
configuración la cadena de conexión, y asà­ ya discrimina si es sql, o
oledb. Esa clase maneja todo el entramado de paso de datos a la base de
datos.

Luego tengo la capa de negocios, que bà¡sicamente tiene tantas clases como
tablas tiene la base de datos, heredando de una génerica las funciones mà¡s
comunes: esto es: traer un registro dado el id, grabar un registro, borrar,
actualizar. Cada clase tiene tantas variables como registros de la base de
datos, es decir si tenemos la tà­pica bbdd con dos tablas: Clientes y
Direcciones, Tendré tres clases: La génerica, de la cual heredaran las
Clases Clientes y Direcciones. La clase Clientes tendrà¡ su Id (que lo
hereda de la génerica), y ademà¡s las variables nombre, apellidos... .
Igualmente, la clase Direcciones tendrà¡ su Id heredado, y como propias las
variables Calle, Población...
Luego la clase Clientes (o Población), tendrà¡ métodos propios que serà¡n
exclusivos, por ejemplo podrà­amos tener un método que nos devolviera el
nàºmero de clientes que tiene una población concreta:

Public Function NumeroClientesEnPoblación(IdPoblacion as Integer) as Integer
dim Consulta as string=SELECT Count(*) FROM Clientes INNER JOIN ...
return MyBase.DevolverValor(consulta)
End Function

Esa serà­a la consulta SQL que le pasarà­a a la clase generica que tendrà¡ un
metodo llamemosle DevolverValor(byval consulta as String) as Integer

Este método llamarà¡ a la clase de acceso a datos que abrirà¡ conexión,
devolverà¡ el resultado y cerrara conexion

Finalmente, en la interfaz, si en un textbox quiero poner el nàºmero de
clientes que se encuentran en la población tal:
Dim miPoblación as new Poblacion
textbox1.text=miPoblación.NumeroClientesEnPoblacion.ToString
miPoblacion=nothing

Espero no haberme enrollado mucho

Yo lo hago as :

Por un lado tengo una clase de acceso a datos, la cual le de un fichero de

configuraci??n la cadena de conexión, y así ya discrimina si es sql, o
oledb. Esa clase maneja todo el entramado de paso de datos a la base de
datos.

Me imagino que eso es algo similar como el ejemplo que aparece
universidad.net
donde crean una clase gdatos, y que maneja todo el acceso, me equivoco o no?

Public Function NumeroClientesEnPoblación(IdPoblacion as Integer) as

Integer

dim Consulta as string=SELECT Count(*) FROM Clientes INNER JOIN ...
return MyBase.DevolverValor(consulta)
End Function

Lo que no me queda claro aqui, es si usas procedimientos almacenados o no?
Por que si envias la consulta directamente me imagino que no, y mi problema
es qe yo si los uso.

Finalmente, en la interfaz, si en un textbox quiero poner el número de
clientes que se encuentran en la población tal:
Dim miPoblación as new Poblacion
textbox1.text=miPoblación.NumeroClientesEnPoblacion.ToString
miPoblacion=nothing

Justo lo que yo deseo, nada de codigo de acceso a datos en la interfase

rafael wrote:

Lo que no me queda claro aqui, es si usas procedimientos almacenados o no?
Por que si envias la consulta directamente me imagino que no, y mi
problema es qe yo si los uso.

Mayoritariamente si (en un 90%)