problemas con la cache de Linqtosql

El Thu, 2 Oct 2008 14:56:15 +0200, Jesús López escribió:

Cierto que es una falta de homogeneidad, pero al menos es posible. Y por
otra parte te ahorras un montón de instrucciones de modificación registro a
registro que siempre son necesarias en las aplicaciones.

No te ahorra nada que no te hubieses ahorrado ya antes una clase del tipo
de DataAdapter.

No es que me guste LINQ to SQL, pero reconozco que con él es posible crear
con éxito aplicaciones

Ya, y también con un teclado que solo tiene un cero y un uno :-)


Saludos
Alfredo

No te ahorra nada que no te hubieses ahorrado ya antes una clase del tipo
de DataAdapter.

Que yo sepa los data adapters no generan insert update ni delete.

Ya, y también con un teclado que solo tiene un cero y un uno :-)

Sin comentarios.



Saludos:

Jesús López

El Thu, 2 Oct 2008 18:45:57 +0200, Jesús López escribió:

No te ahorra nada que no te hubieses ahorrado ya antes una clase del tipo
de DataAdapter.

Que yo sepa los data adapters no generan insert update ni delete.

No, pero te los puede generar un commandbuilder asociado al dataadapter,
que más dará ese detalle.

Lo que quería mostrar es que Linq además de obligarnos a hacer chapuzas
para poder actualizar conjuntos, no aporta ninguna mejora para la
actualización de registros de uno en uno, además de los nuevos problemas
como el de Juanjo.

Por lo que he visto al final hay bastante poca gente que se atreva a usarlo
para cosas serias.

Ya, y también con un teclado que solo tiene un cero y un uno :-)

Sin comentarios.

Es que menuda chorrada, hasta con la peor herramienta se pueden desarrollar
proyectos con éxito, pero quien sería tan tonto como para usar una mala
herramienta pudiendo usar una buena.


Saludos

"Alfredo Novoa" escribió en el mensaje
news:c46exav0e75n.19b1ko8pw0sh7$

El Thu, 2 Oct 2008 18:45:57 +0200, Jesús López escribió:

No te ahorra nada que no te hubieses ahorrado ya antes una clase del
tipo
de DataAdapter.

Que yo sepa los data adapters no generan insert update ni delete.

No, pero te los puede generar un commandbuilder asociado al dataadapter,
que más dará ese detalle.

Es más eficiente y sencillo actualizar con LINQ to SQL que con dataadapter +
commandbuilder..

Lo que quería mostrar es que Linq además de obligarnos a hacer chapuzas
para poder actualizar conjuntos,

Si, exáctamente la misma "chapuza" que de la otra manera: "enviar consultas
sql"

no aporta ninguna mejora para la
actualización de registros de uno en uno,

LINQ to SQL permite un mejor control de la concurrencia optimista. Y un
tratamiento más sencillo de las transacciones que con dataadatper +
commandbuilder.

además de los nuevos problemas
como el de Juanjo.

Lo de Juanjo no es un problema, sólo que no tenía claro algunas cosas.

Por ejemplo tienes un formulario donde cargas y actualizas los datos. Sólo
voy a poner el esqueleto de la parte de carga y actualización:

public class MiForm : Form
{
private MiDataContext dataContext;

public MiForm()
{
InitializeComponents();
dataContext = new MiDataContext();
}

private void Cargar()
{
MiDataGrid.DataSource = (from dataContext.EntidadX where lo que sea
select EntidadX).ToList();
}

private void Guardar()
{
dataContext.SummitChanges();
}

}

Simplemente tienes que mantener una referencia al data context, para leer y
guardar los datos con la misma instancia.

Es que menuda chorrada, hasta con la peor herramienta se pueden
desarrollar
proyectos con éxito,

Lo que sí es una verdadera chorrada es decir que con un teclado con sólo un
cero y un uno puedes desarrollar proyectos con éxito.

pero quien sería tan tonto como para usar una mala
herramienta pudiendo usar una buena.

Alguien quien no sepa cual es la buena y cual es la mala.

Discutamos qué tiene de bueno y de malo LINQ to SQL dando detalles concretos
y comparándolos con otras cosas. Así podremos determinar si realmente es tan
malo como dices, cosa que pongo en duda.

Por ejemplo:

En lo malo: LINQ to SQL sólo funciona con SQL Server. Algunas cosas se han
hecho para hacerlo funcionar con otros motores, pero dudo que hayan tenido
mucho éxito.

En lo bueno: Evita en gran medida la inyección de código SQL.




Saludos:

Jesús López

El Fri, 3 Oct 2008 10:17:30 +0200, Jesús López escribió:

Es más eficiente y sencillo actualizar con LINQ to SQL que con dataadapter +
commandbuilder..

Yo hablaba de clases del estilo del dataadapter, y no especificamente del
dataadapter, por que el dataadapter y ADO.NET en general es otro desastre
como casi todo lo que hace Microsoft últimamente relacionado con las bases
de datos.

También es mucho más sencillo actualizar con mi bindinglist que con LINQ to
SQL, y también es más sencillo con Delphi y con FoxPro y con montones de
otras herramientas de hace 10 años o más.

Lo que quería mostrar es que Linq además de obligarnos a hacer chapuzas
para poder actualizar conjuntos,

Si, exáctamente la misma "chapuza" que de la otra manera: "enviar consultas
sql"

Enviar consultas SQL a través de un "framework" diseñado para no tener que
incrustar consultas SQL en el código. Y además necesitamos crear clases
para cada tabla sin necesidad. Hasta tú has reconocido que andar mezclando
consultas Linq con consultas SQL supone una falta de homogeneidad en el
código, es decir, una chapuza.

no aporta ninguna mejora para la
actualización de registros de uno en uno,

LINQ to SQL permite un mejor control de la concurrencia optimista.

Esto es una chorrada. La concurrencia la controla el SGBD. Lo que aporta
Linq es más complejidad innecesaria.

Por ejemplo en el caso descrito aquí:

http://msdn.microsoft.com/en-us/lib...99373.aspx

Linq lanza una excepción y hace que la actualización falle cuando en
realidad no hay ningún conflicto. Con mi BindingList este ejemplo
funcionaría perfectamente sin lanzar ningún error.

Aquí hay otro ejemplo de conflicto inexistente que además "resuelven" de
una forma absurda.

http://msdn.microsoft.com/en-us/lib...99354.aspx

El resultado lógico es: Alfred, Mary, Marketing, sin ninguna excepción ni
otras gaitas.

Y un
tratamiento más sencillo de las transacciones que con dataadatper +
commandbuilder.

Lo único que te ahorras es no tener que asignarles una transacción a los
SqlCommand. Una mínima automatización que cualquiera se podría montar en 5
minutos en caso de que le interesase. Un detalle de muy poca importancia
comparado con todo lo demás.

Simplemente tienes que mantener una referencia al data context, para leer y
guardar los datos con la misma instancia.

¿Y con esto se te actualizan automáticamente los datos cuando se cambian
desde otra aplicación?

Si es así entonces eso está bien.

Es que menuda chorrada, hasta con la peor herramienta se pueden
desarrollar
proyectos con éxito,

Lo que sí es una verdadera chorrada es decir que con un teclado con sólo un
cero y un uno puedes desarrollar proyectos con éxito.

Si se es un "real programmer" y un machote claro que se puede :-) El
teclado de Chuck Norris solo tiene un 0 y un 1 :-)

Era una ironía, por eso llevaba la sonrisa, pero aquí no te pillan las
cosas ni aun explicándolas como en Barrio Sésamo.

Por ejemplo:

En lo malo: LINQ to SQL sólo funciona con SQL Server. Algunas cosas se han
hecho para hacerlo funcionar con otros motores, pero dudo que hayan tenido
mucho éxito.

La sintaxis es horrible, no permite consultar todo lo que permite SQL, no
tiene instrucciones de actualización , pretende evitar el código SQL
incrustado pero no lo consigue, obliga a definir clases inútiles, es
innecesariamente complejo, no permite trabajar con las expresiones LinQ
como si fuesen expresiones normales, solamente deja cargar en listas, no
permite definir reglas de integridad ni tablas ni vistas en la aplicación,
etc, etc. Cuanto más lo miras en detalle más fallos se ven.

En lo bueno: Evita en gran medida la inyección de código SQL.

Cosa que también evitaba todo lo que había antes desde hace muchos años.


Saludos