Camino a seguir para el acceso a datos

Ya estoy por allí también :)

Un saludo

E.CORTIJO escribió:

Intenta suscribirte a news.defoxa.com alli conseguiras el grupo C# donde
estamos todos aquellos en transición y podriamos ayudarte.

E.C.
"Jose Plus42" escribió en el mensaje
news:

Toca ir cambiando una aplicación realizada en Visual FoxPro a C# y .Net.

¿Pueden aconsejarme sobre que dirección seguir?

La aplicación tiene las siguientes características:
-Es una aplicación de "Gestión" (clientes, facturas, tesorería,...) aunque
centrada en un sector específico.
-Debe trabajar en red local, normalmente sólo 1 usuario simultáneo, aunque
puede haber instalaciones con más (pero siempre números pequeños,
raramente superará los 5, y probablemente nunca llegue a 10).

Hasta ahora trabajaba con tablas libres de Fox perfectamente.

Para la base de datos había pensado que SQL Express es suficiente, pero no
tengo claro como abordarlo. No se si utilizar WebServices, acceder
directamente a la base de datos desde los clientes, meter más o menos
código en procedimientos almacenados, ...

Llevo unas semanas empapándome del lenguaje, pero lo cierto es que en el
acceso a datos estoy bastante perdido. No quisiera quedarme corto ni matar
moscas a cañonazos.

Gracias por su ayuda.

Lo que no he entendido en lo de "Colecciones de entidades de negocio
propias cargadas mediante datareaders y ejecución directa de sentencias
SQL" ¿a qué te refieres exactamente?

Por ejemplo tu tienes una clase que se llama Cliente (Cliente es una entidad
de negocio), con varias propiedades y otra clase pongamos que se llama
DatosClientes que se encarga del acceso a datos y que tendría por ejemplo
los siguientes métodos:

Public Class DatosClientes
' Devuelve una lista de todos los clientes de la base de datos (es una
coleccion de clientes)
Public Function ObtenerTodos() As List(Of Cliente)

'Devuelve los clientes que cumplan un criterio de búsqueda determinado
por los parámetros de búsqueda
Public Function Buscar( criterio As ParametrosBusquedaClientes ) As
List(Of Cliente)

'Inserta un nuevo cliente en la base de datos
Public Sub Añadir(cliente As Cliente)

'Actualiza un cliente en la base de datos
Public Sub Actualizar(cliente As Cliente)

'Elimina un cliente de la base de datos
Public Sub Eliminar(cliente As Cliente)

End Class

Los métodos de carga de datos ObtenerTodos y Buscar devuelven una lista de
clientes, también podría utilizarse otra tipo de colecciones como
ObservableCollection(Of Cliente), BindingList(Of Cliente), etc. Para cargar
los datos se usa un datareader. Por ejemplo:

Public Function ObtenerTodos() As List(Of Cliente)
Using cn As SqlConnection = CrearConexion(), _
cmd As New SqlCommand("SELECT * FROM Clientes", cn)

cn.Open()

Using reader As SqlDataReader = cmd.ExecuteReader()
Dim clientes as new List(Of Cliente)()
while reader.Read()
Dim c As New Cliente()
c.IdCliente = reader("IdCliente")
c.NombreCliente = reader("NombreCliente")
.
clientes.Add(c)
end while
return clientes
End Using
End Using
End Function


Los métodos de actualización, eliminación e inserción utilizan un comando
parametrizado o un procedimiento almacenado para hacer su trabajo. Por
ejemplo:

Public Sub ActualizarCliente(cliente As Cliente)
Using cn As SqlConnection = CrearConexion(), _
cmd As New SqlCommand("UPDATE Clientes SET NombreCliente =
@NombreCliente WHERE IdCliente = @IdCliente", cn)

cmd.Parameters.AddWithValue("@IdCliente", cliente.IdCliente)
cmd.Parameters.AddWithValue("@NombreCliente", cliente.IdCliente)

cn.Open()

cmd.ExecuteNonQuery()
End Using
End Sub


Este ejemplo es muy básico, hay que tener en cuenta muchas cosas y las cosas
se podrían hacer de otra manera, pero creo que sirve para ilustrar la
idea

Nosotros utilizamos este modelo para nuestras aplicaciones, pero tenemos una
pequeña framwork que proporciona clases base para hacer las cosas más
fáciles y rápidas, y generadores de código que nos generan automáticamente
procedimientos almacenados, vistas, las clases de las entidades de negocio y
las clases de acceso a datos (nuestros DatosClientes). Nuestra framework
también detecta y gestiona conflictos de concurrencia.

Como ejemplo de las cosas que puede hacer la framework es cargar una
colección de entidades cualquiera a partir de un datareader con una función
como la siguiente:


Public Sub LoadFromReader(Of T)(lista As IList(Of T), reader As IDataReader)

Nuestra función LoadFromReader es el doble de rápida que cargar un datatable
con un dataadapter. y sirve para cargar cualquier colección que implemente
IList(Of T) a partir de un datareader. Está basada en un poco de Reflection
y DynamicMethod.


Nuestras entidades de negocio no son un mapeo directo de las tablas de la
base de datos, sino que el mapeo se produce entre las vistas y las entidades
de negocio. Y nuestro acceso a la base de datos se produce exclusivamente
por procedimietos almacenados que acceden a las tablas y las vistas.

Nuestras colecciones son ObservableCollection(Of T) y nuestra capa de
presentación es WPF.


Saludos:

Jesús López
www.solidq.com




"Jose Plus42" escribió en el mensaje
news:

Uff... tu respuesta me sirve para ilustrar la gran cantidad de opciones y
decisiones a tomar, y lo perdido que puede llegar a estar uno.

Voy a intentar centrarme en ADO.NET, metiendo el mayor código posible (ya
veré sobre la marcha exactamente cual) en procedimientos almacenados y
Triggers.

LINQ por lo que he leido aún está un poco verde.





Un saludo


Jesús López escribió:

Para una aplicación de 5 a 10 usuarios sería suficiente con SQL Server
2005 Express. Además yo no me complicaría la vida metiendo middle tiers
como web services o WCF, eso sería en el caso de cientos o miles de
usuarios, o que se necesitara acceder por Internet, pero tu tienes pocos
usuarios y están en red local, así que lo más apropiado es una
arquitectura cliente-servidor clásica.

Luego, en cuanto al acceso a datos desde la aplicación cliente al
servidor de base de datos, hay bastantes opciones:

1) ADO.NET directo.
2) LINQ to SQL
3) ORM's como NHibernate.


Si optas por ADO.NET directo todavía tienes que decidir entre usar alguno
de estos modelos:

1) Datasets + DataAdapters.
2) Colecciones de entidades de negocio propias cargadas mediante
datareaders y ejecución directa de sentencias SQL.

También tienes que decidir si te vas a decantar por:

1) Procedimientos almacenados
2) Código SQL incrustado en la aplicación.

Si optas por LINQ to SQL tienes la ventaja de la facilidad de uso, pero
olvídate de que el acceso principal a la base de datos sea por
procedimientos almacenados.


Discutir en profundidad todas las opciones sería demasiado largo. Sólo
decirte que cualquiera de las opciones es válida, personalmente la opción
que más me gusta es la de usar ADO.NET directo, con colecciones de
entidades de negocio propias y acceso a la base de datos por
procedimientos almacenados. Sin embargo esta opción requiere escribir
mucho código, a no ser que tengas generadores de código para generar las
entidades de negocio y las clases de acceso a datos.


Quizá la opción más productiva sea la de LINQ aunque tiene el
inconveniente de que pierdes el control de como se accede a los datos.


Saludos:

Jesús López
www.solidq.com




"Jose Plus42" escribió en el mensaje
news:

Toca ir cambiando una aplicación realizada en Visual FoxPro a C# y .Net.

¿Pueden aconsejarme sobre que dirección seguir?

La aplicación tiene las siguientes características:
-Es una aplicación de "Gestión" (clientes, facturas, tesorería,...)
aunque centrada en un sector específico.
-Debe trabajar en red local, normalmente sólo 1 usuario simultáneo,
aunque puede haber instalaciones con más (pero siempre números pequeños,
raramente superará los 5, y probablemente nunca llegue a 10).

Hasta ahora trabajaba con tablas libres de Fox perfectamente.

Para la base de datos había pensado que SQL Express es suficiente, pero
no tengo claro como abordarlo. No se si utilizar WebServices, acceder
directamente a la base de datos desde los clientes, meter más o menos
código en procedimientos almacenados, ...

Llevo unas semanas empapándome del lenguaje, pero lo cierto es que en el
acceso a datos estoy bastante perdido. No quisiera quedarme corto ni
matar moscas a cañonazos.

Gracias por su ayuda.

No me había dado cuenta de que este grupo es el de csharp y he escrito el
código de ejemplo en Visual Basic. Bueno espero que se entienda de todas
maneras...

Menos mal que lo aclaraste porque yo que a puro trabajo voy aprendiendo un
poco y veo esa sintaxis tan rara... que casi dejo el C# :)


"Jesús López" escribió en el
mensaje news:u8V6D$

No me había dado cuenta de que este grupo es el de csharp y he escrito el
código de ejemplo en Visual Basic. Bueno espero que se entienda de todas
maneras...