Cita:
Iniciado por Wuakap 
Por lo que entiendo deberia ser asi.
DAL: public function leerDocumentos() as data.datatable
BLL: dim MisDatos as new data.datatable = DAL.leerDocumentos
UI: MyGrilla.datasource = BLL.MisDatos
Se entiende que en la BLL sobre ese datatable haras un par de validaciones, setearas ciertas variables y algo que "justifique" la existencia de esa capa, puesto que asi como esta, perfectamente podrias hacer algo asi:
UI: MyGrilla.datasource = DAL.leerDocumentos()
De este modo te saltas la BLL.
De todas formas, al menos a gusto personal, en la BLL siempre declaro variables booleanas, de forma que en la UI pueda hacer algo como esto:
UI: MyBoton.enabled = BLL.estaBotonHabilitado
MyTextbox.readonly = BLL.esTextoSoloLectura
...
De esta forma, el code behind de mi aplicacion (presentacio o UI), solo mantiene llamadas a la capa de negocio y que sea en esta, donde reside la lógica para habilitar o deshabilitar los controles de la interfaz.
NOTA: Ojo, en .NET la presentacion es una clase. En esta tu instancias a otra clase, que sería la BLL. Finalmente, la BLL instancia a la clase DAL. De esta forma el desarrollo por capas contempla a lo menos tres clases.
Claro, tiene su lógica.
Lo que es curioso el tener que ir saltando capas para al final hacer lo que queremos hacer (en tu ejemplo, leer datos de un documento)
Si lo que haces en la capa de datos la hicieses directamente en la de presentación, jerarquicamente está mal, aunque quien sabe si a nivel de rendimiento sería optimo que no ir creando tantos objetos y ir saltando de capa a capa.
Aunque bueno, a nivel de reutilización sería lo correcto. Estoy haciendo pruebas, a ver si cojo la rutina de hacerlo, como se suele decir, como Dios manda
Oye, gracias por la ayuda Crack :)
