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

#11 Leonardo Azpurua [mvp vb]
26/03/2006 - 01:51 | Informe spam
"David Sans" <listas@[QUITAESTO]socaqui.com> escribió en el mensaje
news:
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



Hola, David:

Creo que la intención de Eduardo y mía era explicarte, en primer lugar, que
los metodos de conexión *NO DEBEN SER UNA PROPIEDAD DE TODAS LAS CLASES*.

Las Zonas (o provincias, o clientes, o lo que quieras) no existen por si
solas, sino denro de una aplicacion. Cuando esta aplicacion está trabajando,
lo mas normal es que todas las operaciones de acceso a datos se realicen
contra un mismo origen. De manera que lo mas sensato es delegar todo lo que
tiene que ver con las conexiones a la BD a un objeto Aplicacion.

Las clases que acceden a los datos obtienen la conexión de la aplicacion.

Es decir: es un error conceptual pasar el nombre del servidor, la cadena de
conexion el usuario y la clave de login a cada clase de la aplicacion. Y es
un error conceptual mayor aun, porque ademas de ineficiente y torpe
desperdicia la posibilidad de hacer un uso provechoso de la herencia (el CLR
no acepta herencia multiple, entonces hay que ser muy cuidadoso al decidir
cuales son las clases base y quienes heredarán de ellas) hacer que todas las
clases deriven de un ProveedorDatos.

Por otra parte, las Zonas sirven para clasificar a los clientes. Los metodos
y propiedades tipicos de una zona son Codigo, Descripcion(),
Validar(codigo), Descripcion(codigo), Cargar(Codigo), Actualizar(Codigo,
Descripcion). Si quieres vincular fuertmente (mala idea) las zonas con los
clientes, podrias agregar un metodo Clientes(CodigoZona) que te devolviera
una coleccion con los clientes que pertenecen a esa zona.

En DOO se usa el "Principio de la Responsabilidad Unica" (Single
Responsibility Principle) segun el cual una clase solo debe ocuparse de sus
aspectos esenciales. Un objeto de tipo Zona, no deberia devolverte otros
objetos de tipo Zona. Para ello puedes usar un iterador (donde metes
Abrir(), Abrir(Filtro), Primero(), Siguiente(), Anterior(), Ultimo()) y que
puedes implementar sobre una colección, un DataTable, o un DataReade (un
cursor del lado del servidor). No hay problema con que en el iterador
agregues metodos para buscar una Zona o agregar una nueva Zona.

Salud!
Respuesta Responder a este mensaje
#12 Eduardo A. Morcillo [MS MVP VB]
26/03/2006 - 03:59 | Informe spam
Por otra parte, las Zonas sirven para clasificar a los clientes. Los
metodos y propiedades tipicos de una zona son Codigo, Descripcion(),
Validar(codigo), Descripcion(codigo), Cargar(Codigo),
Actualizar(Codigo, Descripcion).



No te puedo decir exactamente el motivo, pero no me agrada el mezclar el
codigo que trae la data con el de la entidad. Me parece que no es una
solucion muy escalable. Por ejemplo eso no funcionaria muy bien si
trajeramos la data desde un servicio web ¿no?. Me gusta tener la entidad
totalmente separada de lo que es cargar, actualizar y esas cosas, como se ve
en el ejemplo que envie.

Eduardo A. Morcillo [MS MVP VB]
http://www.mvps.org/emorcillo
http://mvp.support.microsoft.com/pr...4EF5A4191C
Respuesta Responder a este mensaje
#13 David Sans
27/03/2006 - 09:10 | Informe spam
Buenas.

Yo también pensaba hacerlo como Leonardo, pero creo que es mejor como tu
dices, ósea como lo tienes en el ejemplo.

El problema que tengo es que aplicación que he de realizar no trabaja con
Sql Server de microsoft. Sino con Sql de Pervasive.

Por lo tanto no puedo Imports System.Data.Common, por que tengo que usar el
proveedor nativo para .net de Pervasive (Imports Pervasive.Data.SqlClient),
lo que voy a mirar si puedo System.Data.Obdc para acceder a Pervasive.

Bueno entre todos los comentarios y ejemplo, voy ha intentar crear las
clases, ya os comentare como va.

Un saludo
David Sans.

"Eduardo A. Morcillo [MS MVP VB]" <emorcillo .AT. mvps.org> escribió en el
mensaje news:%
Por otra parte, las Zonas sirven para clasificar a los clientes. Los
metodos y propiedades tipicos de una zona son Codigo, Descripcion(),
Validar(codigo), Descripcion(codigo), Cargar(Codigo),
Actualizar(Codigo, Descripcion).



No te puedo decir exactamente el motivo, pero no me agrada el mezclar el
codigo que trae la data con el de la entidad. Me parece que no es una
solucion muy escalable. Por ejemplo eso no funcionaria muy bien si
trajeramos la data desde un servicio web ¿no?. Me gusta tener la entidad
totalmente separada de lo que es cargar, actualizar y esas cosas, como se
ve en el ejemplo que envie.

Eduardo A. Morcillo [MS MVP VB]
Respuesta Responder a este mensaje
#14 David Sans
28/03/2006 - 11:04 | Informe spam
Hola Eduardo y grupo.

En el ejemplo que me enviaste hay una cosa que no entiendo:
Has sobrecargado la funcion ExecuteReader, y en una de las sobrecargas

Public Shared Function ExecuteReader(ByVal sqlText As String, ByVal commandType As CommandType) As DbDataReader
Return ExecuteReader(CreateConnection(), sqlText, commandType)
End Function

(Return ExecuteReader(CreateConnection(), sqlText, commandType) ) <-- esta sobrecarga con estos parametros no esta.
Siguiendo con el Debuger veo que coge o a mi me lo parece la ExecuteReader(conexion,string,comando, parametros)
Es normal??

Otra cosa. Para implementar la baja de un registro lo he hecho así (uso acceso a datos con pervasive .net, las sentencias SQL son
diferentes del Microsoft):

En la clase ProvinciaTable
Public Shared Function BorrarProvinciaById(ByVal id As String) As integer
Dim idParam As PsqlParameter = DataHelper.CreateParameter("ID_Provincia")
idParam.Value = id
Return DataHelper.ExecuteNonQuery("Delete FROM Provincias WHERE ID_Provincia = ?", idParam)
End Function

En la clase DataHelper

Public Shared Function ExecuteNonQuery(ByVal sqlText As String, ByVal ParamArray parameters() As PsqlParameter) As Integer
Dim cmd As New PsqlCommand
cmd.Connection = CreateConnection()
cmd.CommandText = sqlText
cmd.CommandType = CommandType.Text
cmd.CommandTimeout = _commandTimeout
SetCommandParameters(cmd, parameters)
Try
cmd.Connection.Open()
Return cmd.ExecuteNonQuery()
cmd.Connection.Close()
Catch ex As Exception
If cmd.Connection.State <> ConnectionState.Closed Then
cmd.Connection.Close()
End If
Throw
End Try
End Function


Crees que lo voy bien?

Otra cosa. La modificación de un registro como iria?

Muchas gracias por anticipado
David Sans





"Eduardo A. Morcillo [MS MVP VB]" <emorcillo .AT. mvps.org> escribió en el
mensaje news:
Siguiendo mi modelo seria como el ejemplo que envio adjunto. Esta en
VB2005 y hay que tener en cuenta que faltan varias cosas porque solo es un
ejemplo, aunque funciona.

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


Respuesta Responder a este mensaje
#15 Eduardo A. Morcillo [MS MVP VB]
28/03/2006 - 17:01 | Informe spam
Es normal porque la sobrecarga ExecuteReader(conexion, string, comando,
parametros) tiene a parametros definido como ParamArray lo que hace que sea
opcional.

Crees que lo voy bien?



Yo cambiaria el Try por:

Try
cmd.Connection.Open()
Return cmd.ExecuteNonQuery()
Finally
cmd.Connection.Close()
End Try

Otra cosa. La modificación de un registro como iria?



Llamarias a ExecuteNonQuery con un UPDATE:

Public Shared Function ActualizarProvincia(ByVal id As String, ByVal nombre
As String) As integer

Dim idParam1 As PsqlParameter =
DataHelper.CreateParameter("ID_Provincia")
Dim idParam2 As PsqlParameter = DataHelper.CreateParameter("Nombre")

idParam1.Value = id
idParam2.Value = nombre

Return DataHelper.ExecuteNonQuery("UPDATE Provincias SET Nombre = ?
WHERE ID_Provincia = ?", idParam2, idParam1)

End Function

Eduardo A. Morcillo [MS MVP VB]
http://www.mvps.org/emorcillo
http://mvp.support.microsoft.com/pr...4EF5A4191C
Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaSiguiente AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida