Problema con una clase heredada.

Es simple: una clase de dominio, por ejemplo Cliente, puede
adicionalmente proveer una interfaz estandar con el usuario (en mi
caso es una forma estandar de interfaz -lo que antes era la pantalla
ABM- y un control para la entrada de los codigos, que activa una
ventana de búsqueda y se ocupa de las validaciones, con la opción de
crear un nuevo cliente como parte de la validacion). Adicionalmente,
este control (ClienteBox) permite acceder a las propiedades del
cliente cuyo codigo está cargado.

¿Pero no te restringe a un IU en particular? Me refiero a que por ejemplo
debes tener esto doble, una vez para web y otra para una aplicacion de
escritorio.

Eduardo A. Morcillo [MS MVP VB]
http://www.mvps.org/emorcillo
http://mvp.support.microsoft.com/pr...4EF5A4191C

"Eduardo A. Morcillo [MS MVP VB]" <emorcillo .AT. mvps.org> escribió en el
mensaje news:

Es simple: una clase de dominio, por ejemplo Cliente, puede
adicionalmente proveer una interfaz estandar con el usuario (en mi
caso es una forma estandar de interfaz -lo que antes era la pantalla
ABM- y un control para la entrada de los codigos, que activa una
ventana de búsqueda y se ocupa de las validaciones, con la opción de
crear un nuevo cliente como parte de la validacion). Adicionalmente,
este control (ClienteBox) permite acceder a las propiedades del
cliente cuyo codigo está cargado.

¿Pero no te restringe a un IU en particular? Me refiero a que por ejemplo
debes tener esto doble, una vez para web y otra para una aplicacion de
escritorio.

En efecto.

Por eso la segmentacion. Las clases que implementan una IU heredan de las
clases que implementan la logica intrinseca de los objetos, pero estas son
totalmente independientes de las primeras. La mayoria de mi trabajo son
aplicaciones de escritorio, por eso el nivel adicional. La intención es
desarrollar un dominio de objetos de negocios, que me permita desarrollar
rapidamente aplicaciones a la medida y que le permita a mis usuarios
desarrollar su propia funcionalidad sin depender de mi. Supongo que incluir
una interfaz gráfica estandarizada para las entidades puede reducir mucho el
tiempo de desarrollo.

En caso de tener que desarrollar una aplicacion Web (o batch, asociada con
dispositivos moviles -he tenido bastante trabajo en esa area) simplemente
utilizao las clases de servidor como DLL de soporte de los scripts de
servidor en ASP, o para usarlas directamente desde el programa que incorpora
la informacion de los moviles a la aplicacion central.

En muchos casos, incluso en la aplicacion, utilizo las clases "cliente"
mediante variables declaradas como instancias de la clase Base. Me pareció
útil agregarle una interfaz "de escritorio" reutilizable y estandar.

El enfoque no deja de tener ciertos problemas: la aplicacion debe "decorar"
las formas estandar de interfaz de las entidades: por ejemplo, en una
aplicacion donde los clientes no realizan pedidos, no puedes incluir codigo
para activar la lista de pedidos del cliente (porque crearia una dependencia
de una clase de dominio con una clase de aplicacion). La estructura es un
poco mas compleja que la de una forma normal. La forma estandar de clientes
tiene una opción etiquetada "Estadisticas y Consultas": cuando el usuario la
pulsa, la forma genera un evento, al cual la aplicacion debe responder segun
sus necesidades particulares. Lo mismo si pulsas "Operaciones", que debe
presentar un menu con las diferentes transacciones que un cliente puede
protagonizar, del cual a su vez se cargaria el formulario para la captura de
la transaccion precargado con los datos del cliente. Todo esto es
independiente del cliente en sí: el cliente al final lo que va a recibir es
la notificación de que un documento (IDocumento está declarada a nivel de
dominio) se agregó a su expediente y eventualmente que se registró una
transaccion en su cuenta (para que ajuste su saldo: eso, y devolver una
colección con los documentos en su expediente, es lo unico que saben hacer:
incluso la presentación de los documentos es responsabilidad de clases
"superiores").

Salud!

y que le permita a mis usuarios desarrollar su propia funcionalidad sin
depender de mi.

Que poca vision comercial ;-) Ya entiendo mas o menos por donde va la idea,
la veo medio enredada la parte el UI pero habria que verlo en la practica.

Eduardo A. Morcillo [MS MVP VB]
http://www.mvps.org/emorcillo
http://mvp.support.microsoft.com/pr...4EF5A4191C

"Eduardo A. Morcillo [MS MVP VB]" <emorcillo .AT. mvps.org> escribió en el
mensaje news:%

y que le permita a mis usuarios desarrollar su propia funcionalidad sin
depender de mi.

Que poca vision comercial ;-)

Eso es el slogan. En la práctica lo que logro es adaptar el sistema a las
necesidades más específicas del usuario sin necesidad de alterar las fuentes
genéricas. Y la frase "les produce la sensacion" de no depender de mi.

Ya entiendo mas o menos por donde va la idea, la veo medio enredada la
parte el UI pero habria que verlo en la practica.

Es simplemente una entidad, de la cual se deriva una nueva entidad con una
IU agregada.

Salud!

Hola.

He empezado el hilo este, pero voy muy perdido.

Mi intención era si alguien me podría orientar a realizar las clases para
mantener las tablas (Provincias, Familias de artículos, Representantes,
clientes .)

Si alguien me puede hacer un esquema de unas clase.

Provincias, con ID_Provincia y descripción
Zonas con ID_Zonas y descripción.
Clientes con ID_Cliente, Nombre,ID_Provincia,ID_Zona.

Como hacer la clase para la cadena de conexión y un poco los esquemas de las
clases para hacer un mantenimiento.
O si tenéis un ejemplo con un par de tablas.

Yo lo estaba haciendo asi:

Clase Zonas
sub new(NombreServer,NombreBaseDatos)
sub new(NombreServer,NombreBaseDatos,Usuario,Password)
funcion NumRegistros as integer
funcion PrimerRegistro()
funcion UltimoRegistro()
Funcion DevuelveTable () as datatable
Funcion DevuelveTable (CadenaSQL) as datatable
Propiedad ID_Zona
Porpiedad Descripcion
end

Muchas gracias.
David Sans