Forums Últimos mensajes - Powered by IBM
 
Tags Palabras claves

Problema con una clase heredada.

23/03/2006 - 19:43 por David Sans | Informe spam
Ayuda Hacer una pregunta
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
email Siga el debateRespuesta 21 respuestasRespuesta Tengo una respuesta

Preguntas similare

Leer las respuestas

#1 Jesús López
24/03/2006 - 08:21 | Informe spam
¿Alguno de los dos usáis strong typed datasets ? ¿y enlace a datos en tiempo
de diseño?

Saludos:

Jesús López
MVP
Respuesta Responder a este mensaje
#2 Leonardo Azpurua [mvp vb]
24/03/2006 - 11:57 | Informe spam
"Jesús López" escribió en el mensaje
news:
¿Alguno de los dos usáis strong typed datasets ? ¿y enlace a datos en
tiempo de diseño?



Yo, para nada.

Pase demasiados años escribiendo texto en una pantalla verde, y desarrollé
limitaciones severas.

Salud!
Respuesta Responder a este mensaje
#3 Eduardo A. Morcillo [MS MVP VB]
24/03/2006 - 15:45 | Informe spam
¿Alguno de los dos usáis strong typed datasets ? ¿y enlace a datos en
tiempo de diseño?



Ni uno ni lo otro.

Eduardo A. Morcillo [MS MVP VB]
http://www.mvps.org/emorcillo
http://mvp.support.microsoft.com/pr...4EF5A4191C
Respuesta Responder a este mensaje
#4 Eduardo A. Morcillo [MS MVP VB]
24/03/2006 - 16:20 | Informe spam
Lo que no me gusta es eso de estar devolviendo DbConnections, DbCommands y
DbDataAdapters porque todavia te queda mucho codigo por hacer para obtener
la data y debes estar preocupandote por abrir y cerrar conexiones. Yo le
dejo ese trabajo a la misma clase con los metodos ExecuteXXXXX, ademas de
tambien poder devolver los objetos DbXXXX si fuera necesario. La idea de
tener la clase generica y luego heredar las especificas para cada SGBD es
mas o menos como la mia con las interfaces y me parece que esta mejor ya que
compartes aquellas consultas que no hace falta cambiar ahorrando trabajo.

Eduardo A. Morcillo [MS MVP VB]
http://www.mvps.org/emorcillo
http://mvp.support.microsoft.com/pr...4EF5A4191C
Respuesta Responder a este mensaje
#5 Leonardo Azpurua [mvp vb]
24/03/2006 - 21:16 | Informe spam
"Eduardo A. Morcillo [MS MVP VB]" <emorcillo .AT. mvps.org> escribió en el
mensaje news:
No se si sera por la hora pero como que no entiendo eso de la interface.
Imagino que tienes algo asi como una interface con los metodos para
ejecutar consultas y luego una clase que implementa la interface y usa
System.Data.Oledb, otra que implementa la interface y usa
System.Data.SqlClient, etc. Creo que esto lo puedes simplificar usando las
interfaces de System.Data o usar las clases de System.Data.Common del
framework 2.0. De ambas formas estarias accediendo en forma directa al
proveedor y de forma independiente a este. Eso es lo que hace mi clase.
Por ejemplo (¿sera correcto poner codigo c# en el foro de VB? :) ):

private static DbProviderFactory _factory;

public static DbConnection CreateConnection() {

DbConnection cnx = _factory.CreateConnection();

cnx.ConnectionString = _connectionString;

return cnx;

}

_factory y _connectionString lo setea la aplicacion y es la unica
interaccion directa entre la aplicacion y esta capa.



Eso es mas o menos lo mismo que hago. La diferencia es que la
responsabilidad de mantener la informacion sobre la conexión en mi caso es
del Contexto de Aplicacion.

Los Objetos Cliente son clases que heredan de los objetos servidor,
a los que agregan una interfaz de usuario estandar.



Aqui me perdi de nuevo.



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.

Decidí separar los componentes de interfaz con el usuario (que siempre estan
en el equipo cliente) de los datos y conductas internos de cada clase. Esto
debería darme mas libertad a la hora de "distribuir" (deploy) la aplicación.
Los componentes que implementan UI, entonces, heredan de los componentes
"silenciosos".

Salud!
Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaSiguiente Respuesta Tengo una respuesta
Search Busqueda sugerida