Problema con una clase heredada.

23/03/2006 - 19:43 por David Sans | Informe spam
Hola grupo.

Tengo el siguiente problema con el VB 2005.

Quiero una clase de acceso a datos y quería tener clase común para todas las
tablas y una clase para cada tabla.

Pongo el ejemplo:

Public Class AccesoDatos
Public Sub New(ByVal NombreServidor as string, ByVal NombreBaseDatos as
string)
' Abrir la conexión
End Sub
End Class


La otra clase seria Provincias

Public Class Provincias
Inherits AccesoDatos
.
.
End Class

El problema me sale cuando heredo de la clase AccesoDatos, que en tiempo de
diseño al dar el intro a Inherits AccesoDatos, me sale el siguiente error
La clase Provincias debe declarar un 'Sub New' porque su clase base
'AccesoDatos' no dispone de un 'Sub new' accesible al que se pueda llamar
sin argumentos.

El error es correcto y la explicación del error también. Pero yo quiero que
no se pueda declarar en otra clase esto:
Dim oProvincia as new Provincias
Quiero que se tenga que declarar así:
Dim oProvincia as new Provincias("SERVER","NORTWHIND")

Como lo puedo solucionar?

Muchas gracias.
David Sans

Preguntas similare

Leer las respuestas

#6 Eduardo A. Morcillo [MS MVP VB]
24/03/2006 - 22:36 | Informe spam
Mostrar la cita
¿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
#7 Leonardo Azpurua [mvp vb]
24/03/2006 - 23:32 | Informe spam
"Eduardo A. Morcillo [MS MVP VB]" <emorcillo .AT. mvps.org> escribió en el
mensaje news:
Mostrar la cita
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!
#8 Eduardo A. Morcillo [MS MVP VB]
25/03/2006 - 03:44 | Informe spam
Mostrar la cita
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
#9 Leonardo Azpurua [mvp vb]
25/03/2006 - 06:54 | Informe spam
"Eduardo A. Morcillo [MS MVP VB]" <emorcillo .AT. mvps.org> escribió en el
mensaje news:%
Mostrar la cita
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.

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

Salud!
#10 David Sans
25/03/2006 - 21:16 | Informe spam
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
Ads by Google
Search Busqueda sugerida