domingo, diciembre 30, 2007

Vade retro, LINQ pro SQL

Hágame caso, y evitará malgastar sus fuerzas: si quiere desarrollar una aplicación seria, apártese de LINQ para SQL. Al menos, de momento...
Llevo varios días descubriendo cosas que no me gustan, pero me he contenido por prudencia. El descubrimiento que ha puesto el último clavo sobre el ataúd del invento tiene que ver con la forma en que se manejan las relaciones maestro/detalles. Pongamos por caso que tenemos dos tablas relacionadas, como Clientes y Pedidos:
LINQ para SQL crea dos clases, con un formato predecible:
public partial class Customer
{
public EntitySet<Order> Orders { ... }
}

public partial class Order
{
public Customer Customer { ... }
}
¿En qué momento se leen los pedidos de un cliente? Por omisión, no cuando se crea el cliente; ni siquiera cuando se accede a la propiedad Orders. Hay que intentar hacer algo con el contenido de la colección para que se dispare la consulta SQL correspondiente, que se parecerá a la siguiente:
select * from orders
where CustomerID = @CustomerID
Hasta aquí, todo es esperable, predecible y aceptable... suponiendo que estamos creando una aplicación con la vetusta arquitectura cliente/servidor. Si vamos a tener cuatro gatos conectados a un servidor local de SQL Server (pues LINQ para SQL sólo soporta, de momento, SQL Server), las cosas nos irán bien. Pero para eso no hacía falta gastar dinero en una subscripción anual a la MSDN. Cómprese un Delphi 7 de segunda o tercera mano, o incluso un Visual Basic "clásico", y sea feliz.
Pero, ¿qué pasa con la programación seria? Cuando usted se trae los datos de un grupo de clientes a la capa de presentación, tiene dos opciones, teóricamente: la carga incremental, o por demanda, de sus pedidos, o traer todos los pedidos en la misma operación que trae el grupo de clientes. En mi libro particular de estilo, la carga "por demanda" no sería aceptable. Cuando alguien pide clientes y sus pedidos, es porque realmente necesita ambas entidades, y en programación multicapas, el pecado mortal de necesidad se llama round-trip; es decir, viaje de ida y vuelta al servidor de capa intermedia. Pero mantengamos las opciones abiertas, y supongamos que cada técnica tiene su uso. Pues bien:
  1. LINQ para SQL no permite implementar la carga por demanda cuando hay una capa intermedia. Para transmitir un registro de cliente, hay que "serializarlo", y eso implica serializar sus pedidos. Adiós lectura incremental de los pedidos.
  2. Y ahora viene lo peor: supongamos que ya estamos resignados a no usar la carga por demanda. El caso es que LINQ para SQL implementa la lectura, en esos casos, de manera asquerosamente ineficiente.
Aquí aparecerá el listo de siempre, que alegará la existencia de unas DataLoadOptions que permitirían desactivar la carga por demanda. En efecto, LINQ para SQL ofrece algo así:
DataLoadOptions dlo = new DataLoadOptions();
dlo.LoadWith<Customer>(c => c.Orders);
dataContext.LoadOptions = dlo;
Pero, si se molestase en comprobar qué es lo que realmente hace dicha opción, comprobaría que, si se leen cuatrocientos clientes, esta opción provocaría que el servidor de capa intermedia lanzase otras cuatrocientos consultas SQL para leer individualmente los pedidos de cada cliente. Sí, es verdad que esta avalancha se produciría de golpe, en vez de incrementalmente...
Las cosas son buenas o malas en comparación con otras. ¿Cómo se resuelve este problema en ADO.NET con los conjuntos de datos de toda la vida? Muy simple: usted sólo necesita lanzar dos consultas, y es ADO.NET quien se encarga de tejer la relación en memoria, una vez que dispone de todos los registros. ¿Quiere, por ejemplo, los clientes de Madrid y sus pedidos? En un mismo comando (¡para ahorrar aún más!) se incluirían dos consultas:
select * from Customers
where City = "Madrid";
select * from Orders
where CustomerID in (
select CustomerID from Customers
where City = "Madrid")
A SQL Server se le da muy bien responder a este tipo de consultas, a pesar de su aparente complejidad. Y no le digo nada sobre recuperar los clientes que hicieron pedidos la semana anterior: la ganancia comparativa sería escandalosa.
¿Conclusión? Pues que LINQ para SQL no está preparado para la vida real. Es un juguetito con ínfulas, que a la hora de la verdad se queda muy corto... y es lamentable que la comunidad de programadores no esté diciéndolo en voz alta. No se trata sólo del problema aquí explicado: hay que sumar los problemas que ya la propia Microsoft explica para el funcionamiento del sistema en tres capas. Por ejemplo: los valores originales de cada registro se almacenan en el contexto, y al serializar un registro se pierden, no existe una funcionalidad comparable al Merge de los conjuntos de datos...
Es cierto que Microsoft se reserva eso del ADO.NET Entity Framework para febrero o marzo (es significativo que hayan publicado Visual Studio 2008 sin esperar por él). Habrá que esperar al producto final antes pronunciarse. Pero cada vez creo menos en la bondad de los ORMs: tengo razones para esperar muy poco de este tipo de sistemas. De todos modos, seré prudente: ya veremos qué tal se comporta el nuevo invento. A lo mejor esta es la vez en que un ORM acierta por primera vez en la Historia...

... y que ahora alguien me diga cuál es la urgencia para aprender a usar LINQ. ¿Para aplicarlo al famoso LINQ para SQL?
Mucho cuidado: no estoy diciendo que no merezca pasarse a VS2008. Todo lo contrario, ¡pásese urgentemente a la nueva versión! Hay suficientes mejoras como para merecer la pena, y la principal de ellas, en mi humilde opinión, es la nueva técnica de generación de clases para conjuntos de datos, que facilita enormemente la creación de aplicaciones en tres capas.

Etiquetas: , , , ,

54 Comments:

Blogger Dario said...

Estimando Ian,

Analizando este post veo que usted no es muy amigo de los ORM's...no soy un experto en el tema pero lo poco que he leido siempre hablan bien de ellos...ahora bien, me gustaria conocer el porque de tus sentimientos hacia ellos.

Gracias

martes, enero 01, 2008 6:53:00 p. m.  
Blogger Ian Marteens said...

Hola, Darío: es una explicación larga, y quería escribir un artículo (y quizás publicarlo sobre papel). Pero te adelanto varios argumentos:

1- La "chicha", la "sustancia", o para ser más exactos, el código que contiene las reglas de negocio y los procedimientos de operación en casi cualquier modelo, no pertenece a las clases Cliente, Factura, etc, etc. O pertenece a colecciones de estas entidades, o a clases de tipo "processor"... los cuáles, de acuerdo a la OOP más purista, son el peor ejemplo posible de clases.

2- Incluso cuando hay reglas de negocio (casi siempre, validaciones muy simples) que se pueden adjudicar a las entidades, es muy mala idea codificarlas directamente en estas clases. Motivo principal: el dinamismo, la naturaleza cambiante de las reglas de negocio. En una situación real, te obligaría a modificar y recompilar la aplicación todas las semanas. Hay friquis que se sentirían contentos ante tal perspectiva, claro :)
3- ¿Qué te ofrece una clase Cliente que no te ofrezca un typed dataset?
4- La pregunta inversa tiene respuesta inmediata: por ejemplo, la funcionalidad de Merge, que falta en LINQ4SQL y que complica tanto escribir una aplicación en capas.

Hay muchas más razones: pregúntate por qué las bases de datos relacionales no han sido desplazadas por los sistemas de bases de datos orientados a objeto. Mi intuición: la dicotomía "valor/identidad". En sistemas distribuidos, es más fácil asumir la naturaleza de copia local de un DataRow que intentar ser consecuentes con la identidad implícita de los objetos. Una confirmación de lo apropiado de la intuición: los conflictos que mencioné al intentar usar LINQ4SQL en tres capas surgen precisamente del intento de mantener la identidad única de cada objeto leído.

Echale un vistazo a la opinión de Anders Hejlsberg:

Inappropriate abstractions

... y tengo incluso la impresión de que Hejlsberg intentaba ser prudente, sabiendo que ObjectSpaces se cocía a sus espaldas en ese preciso momento.

Por supuesto, este es un tema abierto, y me gustaría escuchar opiniones. Yo mismo quiero ser prudente: a lo mejor el Entity Framework termina siendo la maravilla. Pero, mientras tanto, hago de Santo Tomás.

martes, enero 01, 2008 8:08:00 p. m.  
Blogger Ian Marteens said...

Pero sí pongo la mano sobre el fuego para defender mi consejo inicial: no uséis LINQ4SQL para aplicaciones en múltiples capas, al menos, en su estado actual.

martes, enero 01, 2008 8:10:00 p. m.  
Blogger Marto said...

Hola Ian,

Yo trabajo con JavaEE, que sé que no es santo de tu devoción, pero algunos ORM que existen en ese mundo sí solucionan los problemas que planteas en tu post, como por ejemplo Hibernate.

¿Te has mirado Hibernate para .NET? ¿Qué opinión te merece?

Yo he implantado aplicaciones muy serias y con requisitos de rendimiento elevados con éxito y un ahorro de tiempo increíble.

Saludos!

martes, enero 01, 2008 9:59:00 p. m.  
Blogger Ian Marteens said...

Hola, Marto. Sí, he visto NHibernate, pero no he hecho nada con él. ¿Qué ventajas te da, que no tenga un typed dataset?

miércoles, enero 02, 2008 2:13:00 a. m.  
Blogger franklt69 said...

Hola Ian, yo he visto q hay mucho ruido acerca de LinQ, Entity Framework ect, yo no dudo q puedan ser buenas herramientas, pero la realidad es q si las personas quieren hacer grandes sistemas > 150 clases, con facilidades grandes de re-modelar y reajustarse a las nuevas necesidades, usando programacion orientada a objecto, trabajando con los servidodes de bases de datos mas usuales, sirviendo para hacer app en varias capas, client/server/ winform, webapp, services ect, un perfomances aceptable ect, pq no mirar a www.capableobjects.com (ECO) pq eran de borland?, pq usan UML/OCL y no gusta mucho? o pq Microsoft ahora se metio en el mundo MDA y hay q mirar el MDA, en fin la realidad es q hoy yo puedo hacer con el viejo C# builder (.net1.1) + eco + javascript web app q quizas usando los componentes standard de visual studio 2008 me sea casi imposible, pero desgraciadamente el mercado manda y microsoft dice LinQ, Entity Framework MVC, y todo el mundo corre y realmente no ve lo q otros hacen, es asi de triste el mundo pero hay q saber vivir, de todas manera les recomiendo q se bajen la version de Eco for Visual Studio y la evaluen para q vean q la gente de ECO no estan en ese mundo desde 1997 por gusto.

un gran saludo hacia tiempo q no entraba a tu blog el cual me gusta mucho.

saludos Frank

miércoles, enero 02, 2008 2:13:00 a. m.  
Blogger Cristian said...

Yo recomiendo que le hechen una mirada a XPO de DevExpress, www.devexpress.com , es facil de usar y es muy rapido, desearia una opinion de Iam sobre este producto

miércoles, enero 02, 2008 2:38:00 p. m.  
Blogger Marto said...

Hola Ian,

Yo creo que un sistema como NHibernate aporta aspectos que no puedes conseguir con Typed Datasets, pero claro, es muy probable que me equivoque, ya que es posible que algunos de los puntos sí los cubras con Typed Datasets. Lo que yo veo:

1) Hibernate permite trabajar con dos lenguajes de consultas. HQL (Hibernate Query Language), además de funcionar para todos los motores de bases de datos, ya que al final se traduce al SQL nativo que esté configurado, se diferencia de SQL en que no se consultas tablas, sinó clases y sus dominios. Te pongo un ejemplo sacado de la web de hibernate de la misma query en sql y hql ( aqui)

SQL:

SELECT cust.name, cust.address, cust.phone, cust.id, cust.current_order
FROM customers cust,
stores store,
locations loc,
store_customers sc,
product prod
WHERE prod.name = 'widget'
AND store.loc_id = loc.id
AND loc.name IN ( 'Melbourne', 'Sydney' )
AND sc.store_id = store.id
AND sc.cust_id = cust.id
AND prod.id = ALL(
SELECT item.prod_id
FROM line_items item, orders o
WHERE item.order_id = o.id
AND cust.current_order = o.id
)

HQL:

select cust
from Product prod,
Store store
inner join store.customers cust
where prod.name = 'widget'
and store.location.name in ( 'Melbourne', 'Sydney' )
and prod = all elements(cust.currentOrder.lineItems)


De todas formas, si quieres especificar alguna de tus consultas mediante sql, tambien puedes

2) Hibernate permite queries polimórficas, pudiendo representar facilmente modelos realmente OO en la bd relacional.
3) Hibernate automatiza muchas tareas como la paginación de forma trasparente y optimizada (no pagina en memoria, sino que crea el sql necesario para cada base de datos para reoger los registros necesarios cada vez)
4) Por defecto, las colecciones se cargan mediante lazy loading, pero en cada relación se puede especificar que no lo haga
5) Puedes dejar que las consultas para cargar relaciones se generen solas o especificarlas tú.

mmm, no sé, estas son unas cuantas que se me han ocurrido, pero seguro que hay mas ;)

miércoles, enero 02, 2008 3:24:00 p. m.  
Blogger Ian Marteens said...

Hibernate automatiza muchas tareas como la paginación

Esta es una de las dos ventajas que veo en la lista... pero no es intrínseca de un ORM. Un typed dataset podría incorporarla, siempre que aceptase cierta dependencia del proveedor SQL. Observa el peligro latente (en mi opinión, el riesgo es aceptable).

Lo de "intrínseco" lo recalco: se trata no de las ventajas que un determinado ORM tenga sobre una implementación particular de datasets.

HQL (Hibernate Query Language)

Y esa es la segunda ventaja. Pero eso ya lo hacía, por ejemplo, Proteus. No es una ventaja exclusiva de un ORM. De hecho, para un ORM es más complicado que para un sistema basado en datasets como Proteus.

En ninguna de las ventajas mencionadas hay algo que se asocie específicamente con tener una clase Cliente "libre de restricciones en la base" (como quieren los fans del movimiento POCO/POJO) o que sea complicado lograr con typed datasets.

-------------------------

Ahora, a la inversa: veo que no has mencionado nada sobre multi-tier... Mi predicción es que a los ORMs les cuesta muchísimo más soportar las tres capas que a los datasets. Y que cuando lo logran es a costa de prostituir el puro modelo original para asemejarlo a uno basado en datasets.

Para empezar, tienen que almacenar la información diferencial (antes/después) en el propio registro, o trabajar con colecciones ad hoc (datasets!). Y tienen que renunciar al modelo de identidad en favor del concepto de copia local. Adiós Poco Pojo.

--------------

Nota: POJO = Plain Old Java Objects, POCO = Plain Old C# Objects, movimientos puritanos y reformistas. En síntesis mnemotécnica: Poco Mojo en el Pojo.

miércoles, enero 02, 2008 5:32:00 p. m.  
Blogger Ian Marteens said...

pq usan UML/OCL y no gusta mucho?

Pues sí, por ejemplo. ECO no gusta a los fans de los datasets como yo por razones obvias... pero tampoco a los puristas, porque va en contra precisamente del concepto POJO.

un gran saludo hacia tiempo q no entraba a tu blog el cual me gusta mucho

Gracias. Te enlazo luego: tengo una lista de enlaces por subir bastante grande.

miércoles, enero 02, 2008 5:36:00 p. m.  
Blogger Ian Marteens said...

desearia una opinion de Iam sobre este producto

Con la misma salvedad que sobre NHibernate (que no lo he usado en aplicaciones reales): ¿qué te ofrece que no te de un typed dataset?

Ojo, no estoy diciendo que sean malos. Por el contrario, puede incluso que sea muy bueno (Remote Objects creo que tiene algo parecido). Lo que me planteo es la relación costes/beneficio: ¿merece la pena lo que se obtiene a cambio del esfuerzo adicional (y la plata extra, en este caso)?

Por cierto, creo que el producto de RO soporta tres capas. Pero sospecho, por mi razonamiento, que lo hará incorporando muchas técnicas más propias de datasets.

Ah... si alguien escribe algo en su blog sobre el tema, que me pase el enlace para añadirlo en el artículo.

miércoles, enero 02, 2008 5:42:00 p. m.  
Blogger Marto said...

Buenas,

Esta es una de las dos ventajas que veo en la lista

¿Y el resto no son ventajas?

2) Queries polimórficas, ejemplo:

Tenemos un sistema que admite dos tipos de usuarios, los que gestionan el backoffice y los que se conectan a la web publica. Ambos tienen la mayoria de atributos iguales i algunos especificos. En el modelo hacemos el diseño evidente (Usuario con las propiedades comunes, UsuarioBO y UsuarioWeb con los específicos y heredando de Usuario). Lo chulo está en que ahora podemos seguir distintas estrategias para representar nuestro modelo en la base de datos. Uno podria ser una tabala para cada clase, con una relacio 1-1.
Despues de marcar un par de configuraciones (en xml o mediante anotaciones) para indicar la estrategia de persistencia, podríamos codificar lo siguiente (en java, que es lo que sé):

Query query = entityManager.createQuery("select u from Usuario u");
List<Usuario> list = query.getResultList();

for (Usuario usuario : list)
{
System.out.println(usuario.getClass().getSimpleName();
}


La gracia está en que, para cada posición de la lista, Hibernate habrá instanciado correctamente cada usuario, siendo un UsuarioBO o un UsuarioWeb segun corresponda. De hecho, la forma buena de implementar este ejemplo sería declarando la clase Usuario como abstracta.

4) Carga por lazy loading segun el gusto y 5) posibilidad de generación de las queries automáticas o a mano... creo que no hace falta explicar estos casos... ¿por qué no te parecen ventajosos?


pero no es intrínseca de un ORM

¡¡Correcto!!, pero yo no dije tal cosa, dije Hibernate en concreto.... estando disponible para .Net me sigue pareciendo excelente. De todas formas, los otros ORM java que conozco (como toplink de oracle) tambien incluyen estas características.


En ninguna de las ventajas mencionadas hay algo que se asocie específicamente con tener una clase Cliente "libre de restricciones en la base"

mmm es verdad, y no creo que exista ninguna virtud intrínseca en los pojos. Yo creo que esta historia viene de la época de ejb 2. En ella los ejb, tanto los de entidad como el resto, eran clases que extendían de otras clases bastante pesadas. El invento fue un fiasco, con todos los problemas de rendimiento que acarrearon, además de plantear una curba de aprendizaje bastante bestia. Si no me equivoco, la moda de los pojos la implantaron los chicos de Spring que, ademas de implementar monadas como "inversión del control" (IoC) o la inyección de dependencias, tambien implementaron un contenedor similar al de los ejb pero basado en en pojos... es lo que llaman frameworks ligeros. De todas formas, yo creo que el problema estaba en los ejb, no la virtud en los pojo. La nueva versión de ejb resuelve esos problemas y la verdad es que es una gozada programarlos.

(joer, que rollo de respuesta me ha salido)

Ahora, a la inversa: veo que no has mencionado nada sobre multi-tier... Mi predicción es que a los ORMs les cuesta muchísimo más soportar las tres capas que a los datasets. Y que cuando lo logran es a costa de prostituir el puro modelo original para asemejarlo a uno basado en datasets.

Pues no mencione el tema de las capas porque desconozco si hibernate aporta algo distinto a ADO.net. En cualquier caso, no se me ocurre que tengan ningun problema para soportar las tres capas. Existen métodos para inicializar colecciones que esten con lazy loading antes de pasar a la capa de presentación (de forma que podemos controlar si lo queremos cargar o no) y existe un método merge para volver a "meter" una entidad que se ha salido de la capa de persistencia otra vez dentro.... no sé, si me planteas en qué dice tu intuición que puede tener problemas te intentaré contestar ;)

Saludos y perdon por lo extenso del comentario!!!

miércoles, enero 02, 2008 11:10:00 p. m.  
Blogger Marto said...

Por cierto, se me olvidaba.
Es cierto que un problema de NHibernate es el no ser de Microsoft. En un mundo en que todo pertenece a MS y MS toma las decisiones de hacia donde va su plataforma, resulta un riesgo evidente montar toda la persistencia con un proyecto que no sea suyo.
Esta es una de las ventajas del mundo java: la evolución de la plataforma se decide en una especie de comité formado por las principales empresas que lo soportan (Sun, IBM, Red Hat, etc.) y tienes más dónde elegir sin tener miedo a que te dejen tirado... pero esto sería otra discusión, ¿no Ian? ;)

miércoles, enero 02, 2008 11:18:00 p. m.  
Blogger Ian Marteens said...

Saludos y perdon por lo extenso del comentario!!!

¡Por el contrario! Son los comentarios lo que le dan vida a un blog.

2) Queries polimórficas, ejemplo:

Creí que te referías a otra cosa. Sí, esa es una ventaja.

Otra cosa es el conflicto que se produce entre implementar la funcionalidad de esas clases en el cliente, o en el servidor, como procedimientos almacenados (yo soy muy de procedimientos almacenados). Ahí el "fallo" lo tiene el modelo relacional, pero entonces habría que ver por qué no han triunfado las BBDD OOP. En mi época de universidad estuve metido en "sectas" dedicadas a la investigación de BBDD OOP: los principios son aparentemente sencillos, pero la realidad es que no han logrado desbancar al modelo relacional.

4) Carga por lazy loading segun el gusto

No me parece una ventaja: en tres capas, el lazy loading es un desastre. Mira que escribo mi "artículo protesta" cuando descubro la chapuza que se da como alternativa al lazy loading: lo primero que he ido a mirar en LINQ4SQL ha sido eso mismo.

o la inyección de dependencias

He visto usar la frase en otro contexto. En este, ¿tiene que ver con programación orientada a aspectos? Si es eso, es un verdadero diagnóstico de la mentalidad Pojo: no se quiere complejidad, y se reintroduce por la puerta trasera. Si fuese eso, claro...

En cualquier caso, no se me ocurre que tengan ningun problema para soportar las tres capas.

Te lo planteo en términos de LINQ4SQL. Puede que Hibernate lo tenga resuelto (adoptando técnicas de datasets contrarias al pocopojo):

LINQ4SQL no representa la versión original de un objeto en el propio objeto (como lo hace un DataRow), sino que es parte del contexto. No habría, en principio, gran problema en hacer que un Cliente tuviese una referencia interna (anulable) a un segundo Cliente, que se crease al intentar modificar cualquier propiedad. Pero el estilo mojopoco exige que toda esa parafernalia esté fuera de Cliente. En Linq4Sql, se almacena en el contexto (DataContext). Existe, efectivamente, un Attach, para asociar un objeto recibido desde la capa de presentación, a un contexto. Problema: ya no tienes el estado original. Si tuviste la posibilidad de usar columnas "timestamp" para la concurrencia optimista, no es gran problema para implementar esa verificación... pero, cuando realices la grabación, de todos modos vas a tener problemas para propagar los cambios inyectados por el servidor a la capa de presentación. Claro, siempre se puede tirar todo y releer, pero ya empezamos con problemas de eficiencia.

¿Que todo lo anterior se puede resolver? Pues claro que sí. Pero entonces tus clases de entidades se parecen extraordinariamente a las clases de filas de un typed dataset.

la evolución de la plataforma se decide en una especie de comité

Es un problema personal: odio los comités.

miércoles, enero 02, 2008 11:40:00 p. m.  
Blogger Marto said...

Buenas,

No me parece una ventaja: en tres capas, el lazy loading es un desastre.

mmmm, es un desastre si la carga dinámica la dispara el cliente, pero en la mayoría de casos es excelente si se produce en la capa intermedia. Por eso te comentaba lo de los métodos de inizialización... supon que tengo una clase Cliente con una colección de facturas y otra de sedes, y yo quiero pintar los datos del cliente y una tabla con sus facturas (pero no las sedes). En el método de la capa intermedia tendré algo así:.

Query q = entityManager.createQuery("select c from Cliente c where c.id = :id");
q.setParameter("id", 23);
Cliente c = (Cliente)q.getSingleResult();
Hibernate.initialize(c.getFacturas());
return c;

Además, si en la configuración le digo que la coleccion facturas no sea lazy, no hará falta el initialize.


cuando descubro la chapuza que se da como alternativa al lazy loading

Si lo que quieres es recoger todas las facturas de todos los clientes, puedes hacer los siguiente

Query q = entityManager.createQuery("select f from Factura f where f.cliente.ciudad = 'Madrid');

Y através de factura.cliente accedes al cliente.

Por último, pero lo más importante.... si todo esto no es lo sufucientemente fino para una consulta en concreto que necesite un tratamiento muy particular.... pues te picas la consulta en SQL!!!! pero solo te picarás esa, no toda la aplicación. Para que te hagas una idea del nivel de personalizción que te permite (o para implementar cosas que no cubra), puedes hasta definirte tus tipos de datos y especificar de una forma muy simple como leerlos (forma, por ejemplo, de optimizar el acceso a campos lob)

En este, ¿tiene que ver con programación orientada a aspectos?

No, la inyección de dependencia es una técnica de inversión del control. Es un tema bastante extenso, puedes encontrar más info aquí.


LINQ4SQL no representa la versión original de un objeto en el propio objeto (como lo hace un DataRow), sino que es parte del contexto

Reconozco que el concepto de tener los valores originales del objeto no existe en Hibernate ni, creo, en otros ORM. Eso sí, permite comprobar timestamping contra la base de datos (como tu decias) o versionado... aunque no he explorado mucho esta última técnica ya que con el timestamping me ha sido suficiente siempre.


¡Ah! Y lo que no me convence es lo de que no hayan triunfado las bases de datos OO... es cierto, pero aqui no hablamos de eso, si no de ORM, que sí estan triunfando (si sacamos la cabeza del mundo MS, claro). Yo creo que el problema delas BD OO tiene que ver con la explotación de información para temas de datamining, y esa es otra pelicula ;)

Saludos!!!

jueves, enero 03, 2008 3:11:00 p. m.  
Blogger franklt69 said...

Marteen, de nuevo seria injusto comparar a ECO con herramientas como XPO de DevExpress, www.devexpress.com ect, no pq uno sea mas malo q otro ect, sino pq son cosas diferentes, ECO Framework de por si es mas q un ORM (object relation mapping) ECO ademas de permitir herencia, polimormisfo en fin todo lo de programacion orientada a objecto, tiene desde un mecanismo de sincronizacion estupendo, quiero decir q puedes tener varias app client (winform o asp.net) q cdo el ECOSpace de uno cambia pues los otros client si deseas pueden sincronizarse, tienen mecanismos de transaciones poderosos ejemplos supon q tiene el modulo de pedido en mysql la contabilidad en oracle y el inventario en sql server, pues puedes comenzar una transacion q involucre q todos esos back end si algo falla pues se hace roolback (ojo son diferentes backend), tiene mecanismos de Undo/Redo de los datos, tiene State Diagram, muy util cdo una order pasa por diferentes states, (en fin pa modelar los states de los objetos) como modelar eso con condiciones ect, tiene control para guardar versiones de un mismos objecto, es decir puedes guardar los objectos con diferentes valores en el tiempo, en cuanto a concurrecia, tiene el concepto de regiones, bien poderoso, tiene algo parecido a lo q en Midas era el modelo briefcase, puedes hibernate el ecospace, guardarlo, apagar el pc, despues cargarlo y contiuar la edicion, desde el punto de vista de IDE ademas de tener un disenador de clases como es EcoModeler, pues permite hacer ingenieria inversa a una base de dato ya creada, es decir supon q tienes ya creada tu bd y quieres hacer una app ECO q use esa pues lo puedes hacer, supon q en proceso de desarrollo de una app tienes q variar el modelo pues tiene lo q se llama Envolve Scheme, modificar el modelo y el sabe lo q hay q hacer en la bd para modificarla y no perder los datos q ya tenias, (creo q eso no esta ni en Entity Framework) tiene lo q se llama autoform tanto pa winform app como asp.net q no es mas q comenzar a meter datos pero siguiendo el modelo q se hizo, quiere decir q no tienes q crear ningun GUI pa meter dato y probar si esta bien o no modelado la problematica, lo cual ahorra mucho time a la hora de modelar, en fin la idea q quiero transmitir es q no se puede ser absoluto en decir q x soft es mejor q otro, cada problematica se resuelve en x momento con la mas adecuada herramienta, lo real es q tampoco puedes comparar ORM con ECO Framework ect pq es comparar naranjas con manzanas.

Respecto a UML Marteen al final ECO lo q usa son Diagrams de Clases y de State q Entity Framework usa tambien Diagrams de clases de State creo q no tiene a no ser el Work Flow, pero no se si es es parte de Entity Framework, respecto a obtener los datos ECO usa OCL y EntityFramwerk LinQ pero al final es lo mismo la diferencia es q puedes usar LinQ en un array en memoria por ejemplo y OCL se usa pero contra ECO clases en fin q quien ha trabajando con ECO ve Entity Framework y realmente no le ve nada novedoso al contrario en prestaciones se queda por debajo de lo q hace ECO al menos hasta el momento estoy hablando de ECOIV ok.


bueno un saludo nuevamente, de un paisano de la habana

Frank

jueves, enero 03, 2008 5:09:00 p. m.  
Blogger Ian Marteens said...

pero en la mayoría de casos es excelente si se produce en la capa intermedia

:) :) :)

Principio de Marteens: en la capa intermedia no existe "después".

Para propiciar la escalabilidad, la capa intermedia debe ser "stateless" (idea, por cierto, que choca frontalmente con el paradigma orientado a objetos, y que tiene muchas consecuencias). Además, las operaciones deben ser lo más breve posible, para no colapsar el servicio. No hay forma de decir: "ahora cargo los pedidos de Juanito y luego los de Pepito"... porque ese "luego" nunca llegará.

jueves, enero 03, 2008 8:27:00 p. m.  
Blogger Marto said...

Principio de Marteens: en la capa intermedia no existe "después".

Totalmente de acuerdo...
Cuando digo lazy loading no me refiero a ahora cargo una cosa y después otra, si no a, cargo lo que necesito.... pero de una vez.

Lo que no tengo claro es qué implementas tú en la capa intermedia... ¿al final estás picando el sql en el cliente no? (ahora viene cuando me mata) :D

jueves, enero 03, 2008 8:53:00 p. m.  
Blogger Ian Marteens said...

No, no te voy a matar, porque la verdad es que incluso ahí soy poco "ortodoxo". Mis "capas intermedias" no tienen nada que ver con el modelado conceptual, sino que es un concepto bastante físico, obligado por el problema del rendimiento. En pocas palabras: SQL no es malo. Lo malo es el modelo de conexión con mantenimiento del estado típico de la arquitectura cliente/servidor. Esa es la causa de que el 90% de los proyectos de Informática terminen en fracaso (el 1% restante son los que me han hecho caso, y el resto se arregla mediante una tremenda inversión de pasta y compra masiva de licencias de Citryx). Los objetos son buenos... siempre que no sobrepasen la barrera del ordenador.

Por cierto, muchos de los problemas que se supone que resuelven los lenguajes de consulta "orientados a entidades" se resuelven también con una simple consulta SQL. Lo que ocurre es que, a los freaks del movimiento POJO, no los dejan acercarse a menos de diez metros de un servidor SQL, y han terminado por imaginarse a un servidor SQL como una especie de caja radioactiva y malvada que es mejor hacer como si no existiese.

jueves, enero 03, 2008 9:50:00 p. m.  
Blogger Alfredo Novoa said...

Hola Ian,

No, no te voy a matar, porque la verdad es que incluso ahí soy poco "ortodoxo". Mis "capas intermedias" no tienen nada que ver con el modelado conceptual,

Al contrario, eres ortodoxo. Si tus capas tuviesen algo que ver con el modelado conceptual sería muy grave, por decirlo de forma suave :-).

sino que es un concepto bastante físico, obligado por el problema del rendimiento.


Las "multicapas" bien entendidas son un concepto puramente físico. Las capas lógicas siguen siendo 2: cliente/servidor, sigue siendo una arquitectura cliente/servidor.

Aquí lo explican bastante bien:

Client/Server Software Architectures--An Overview


A las aplicaciones cliente les da igual el número de capas físicas del servidor. Lo lógico sería que no hiciese falta tocar las aplicaciones cliente para pasar de 2 capas a las que quieras.

SQL no es malo. Lo malo es el modelo de conexión con mantenimiento del estado típico de la arquitectura cliente/servidor.


¿Entonces propones usar algo como UDP?

Una vez desarrollé un sistema de 3 capas desconectado usando TCP/IP y me arrepentí un montón. Conectar y desconectar todo el rato era muy costoso, y además me tenía que currar yo el mantenimiento del estado. Ahora uso TCP/IP pero manteniendo la conexión y mucho mejor todo.

Lo que ocurre es que, a los freaks del movimiento POJO, no los dejan acercarse a menos de diez metros de un servidor SQL


Yo no les dejaría acercarse a un ordenador :-)

miércoles, enero 09, 2008 4:05:00 p. m.  
Blogger franklt69 said...

Alguien podria darme detalles acerca de q es POJO es decir pa q se usa, por arribita en q consiste?

Como algo informativo para todos pongo algunas comparativa de LINQ, Entitity Framework y ECO, es bueno compartir experiencia, y es saber de las personas q trabajan con Entity Framework su experiencia

Esto es sacado de los newsgroup de eco


Ok, below is a rough comparison of development approaches that MS
suggests and the one that Eco offers:

1) Entity inheritance:

Linq to SQL - NO
Linq to Entities (beta) - YES
ECO - YES

2) Many-to-many associations between entities:

Linq to SQL - NO
Linq to Entities (beta) - YES
ECO - YES

3) UML compilance (modeling entities as classes, not tables):

Linq to SQL - NO
Linq to Entities (beta) - NO
ECO - YES

4) DB schema generation from high-level entity model:

Linq to SQL - NO
Linq to Entities (beta) - YES
ECO - YES

5) Linq support (quering directly with C# language)

Linq to SQL - FULL
Linq to Entities (beta) - FULL
ECO - PARTLY (in-memory only)

6) OCL quering:

Linq to SQL - NO
Linq to Entities (beta) - NO
ECO - YES

7) In-memory undo/redo features:

Linq to SQL - NO
Linq to Entities (beta) - NO
ECO - YES

8) Executable state machines:

Linq to SQL - NO
Linq to Entities (beta) - NO
ECO - YES

9) Query-Language:

LINQ - full typesafe, compile check, Intellisense support,
extremely powerful and extendable
ECO - no compile check, no type check (OCL-strings are
just interpreted, but syntay check with OCL editor)

There are always pros and cons concerning interpretation vs. compilation

10) SQL support

LINQ - supports queries, update, insert, delete, transactions,
views and stored procs
ECO - supports queries, update, insert, delete

11) OR mapping

LINQ - reverse modelling only (from existing DB tables to an
object data model using partial classes, no DB evolve)
LINQ to E. - both ways "should" be possible

12) "Clever" object loading

LINQ - NO
ECO - Lazy fetching, explicit prefetching (EnsureRange)

13) ObjectSpace and Services

LINQ and LINQ to E - NO
ECO - Yes lots of powerful services (e.g. subscription) and a
really clever object maintenance

14) Modelling

LINQ separates the object elements that are stored in DB tables (A) from the
other elements like methods and transient attributes (B) using partial
classes.
-> You can concentrate on the piece of code for B and dont need to "see" the
code for A
-> This is a bad (at least strange) kind of modelling domain objects
-> There is no integrated access to the B elements with LINQ (I think you
can't use DB attributes and derived attributes in the same LINQ statement)
-> No state charts, but there may be an integrated Windows Workflow solution
in the future

ECO uses UML modelling
-> Popular, proven, fits perfectly to graphic modelling
-> Access to transient and non transient attributes, access to methods =>
powerful OCL and EAL
-> mix of auto generated(maintained) and user code (Codegen problems with
together modeler!)
-> need for an additional modeler

15) Existing "ECO like" VS Tools

For example: Vanatec Open Access:
- Uses a so called "Scope" that is similar to the EcoSpace
- Lazy fetching and preloading options with an in depth adjustable "fetch
plan"
- Integrates LINQ and uses OQL (Object Query Language) that is similar to
OCL
- Reverse modelling with evolve
- Transactions within the Scope (similar to EcoSpace)
- No Undo/Redo
- Caching: first level, second level, compiled queries, prepared statements


Saludos Frank

jueves, enero 10, 2008 12:41:00 a. m.  
Blogger Alfredo Novoa said...

franklt69, puedes buscar lo de POJO en Google o la Wikipedia. Son unas siglas chorras.

Respecto a la comparativa, parece que ECO es el que cae en más errores seguido de Linq to Entities.

jueves, enero 10, 2008 1:43:00 p. m.  
Blogger franklt69 said...

Hola Alfredo porque dices que

"ECO es el que cae en más errores seguido de Linq to Entities" ?

Segun entiendo yo es como q el enfoque q siguen esos frameworks son de por si un error y el enfoque correcto es sql nativo y directo?


Yo creo lo sgte, no estoy a favor de todo hacerlo directamente en sql (llamalo transat o el lenguaje q quieras) aunque es realmente lo mas eficiente y optimo tiene desventajas como portabilidad y mantenibilidad de el code, por otra parte usando enfoques como Entity o ECO, tienes la ventaja de portabilidad a otras bases de datos y el codigo es mantenible, sobre todo cdo hablo de aplicaciones q tiene mas de 300 tablas, el punto es q es una relacion de compromiso, hacerlo todo en assembler es lo mejor mas optimo ect, pero mas dificil de mantener, de modo q mi enfoque ha sido uso los enfoques de MDA (model driven architecture) o pa simplificar modelos de clases usando programacion orientada objetos con diagrams de states (state machines) de esa manera mi aplicacion puede se explicada sin ver casi code alguno a cualquier developer y este mas facilmente entenderlo, cdo necesito perfomance pues nada me impide ir directo a sql hacer el query q quiera y retornar a el framework de trabajo, es decir el sql siempre esta ahi para cuando lo necesito, en fin es una relacion de compromiso como te dije arriba, entre perfomance vs (manteninibilidad y portabilidad) pq esta ultima es buena tambien, es decir hacer una app con mas de 300 clases (por poner un numero) y q despues puedas usar practicamente la base de dato q quieras es algo bueno para mi.

saludos Frank

jueves, enero 10, 2008 2:48:00 p. m.  
Blogger Alfredo Novoa said...

Hola Alfredo porque dices que

"ECO es el que cae en más errores seguido de Linq to Entities" ?

Segun entiendo yo es como q el enfoque q siguen esos frameworks son de por si un error y el enfoque correcto es sql nativo y directo?


Pues si, el enfoque que siguen todos es de por si un error. El enfoque correcto sería poder trabajar directamente con las tablas como si fuesen cualquier otra variable de la aplicación y poder aplicarles todos los operadores típicos de las tablas. Lo más cercano a esto es LinQ to SQL, aunque tampoco es que se acerque mucho.

Y por supuesto, la lógica de negocio es responsabilidad del SGBD, que para eso está. Las responsabilidades de las aplicaciones son la presentación y la comunicación.

SQL es de mucho más alto nivel que Java, por lo tanto el código SQL es mucho más fácil de mantener. Hay mucha más diferencia en nivel de abstracción entre SQL y Java que entre Java y ensamblador.

La mejor forma de explicar lo que hace un sistema es el texto. Los verdaderos programadores no necesitan diagramas :-)

http://www.cs.utexas.edu/users/EWD/ewd06xx/EWD696.PDF

Lo de poder cambiar un SGBD por otro sin trabajo, aunque en la práctica es poco importante, está bien si el precio a pagar no es alto, pero por desgracia si usamos uno de esos engendros el precio a pagar es altísimo y no compensa en absoluto.

Es mucho más frecuente cambiar de lenguaje de programación de aplicaciones que de SGBD, por lo que cuanto más metamos dentro del SGBD menos probabilides habrá de tener que reescribirlo.

Además al ser SQL de mucho más alto nivel escribiremos mucho menos código. Si hay que cambiar de SGBD tendremos poco código que reescribir y al ser todos los dialectos SQL bastante parecidos habrá que hacer muchos menos cambios que si cambiamos de Delphi a C#, por ejemplo.

Por cierto ¿Alguien ha probado a crear 300 typed datasets de muchas columnas?

Yo si, y eso me hizo descartar ADO.NET al instante.

jueves, enero 10, 2008 5:03:00 p. m.  
Blogger franklt69 said...

Acerca de cambiar el backend:

Alfredo no comparto 100% contigo q el backend raramente se cambia, este es un simple escenario por ejemplo supon q tienes hecho una aplicacion con SQL server un ERP por ejemplo, el hacer eso te estas amarrando a solo poder venderle el sistema aquellos usuarios q tenga esa base de dato o quieran instalarlo, si tienes un potencial cliente q ya tiene oracle comprado o cualquier otro backend el cual no le resulta de interes instalar un nuevo servidor de bd pq ya tiene soporte ect con el q compro pues ese cliente lo pierdes. Al igual q si el client tiene su server en linux por ejemplo con mySQL en fin q contar con q tu app trabaje con cualquier backend no es una caracteristica raramente deseada.
Puedes verlo con un ejemplo practico aqui http://www.opensourcestrategies.com/ofbiz/index.php

repecto a SQL y assember:

Lo q quise decirte es q para los servidores de bd el sql viene siendo como su assembler el lenguaje q puedes sacarle el mejor rendimiento, en fin q puedes crear el query como mejor crea q se ejecutara, quizas ahi los framework te aislen y ciertos querys sean menos eficientes, pero te repito esa puerta siempre esta abierta desde los framework.

Acerca de dialecto parecido y facil migracion:

No creo q eso es una tarea trivial, sobre todo los servidores tienen tipos de datos diferentes, las fechas le dan cada uno el tratamiento q desea, en fin en un sistema por ejemplo como ofbiz (http://www.opensourcestrategies.com/ofbiz/index.php) q tiene mas de 700 tablas no creo q sea trivial cambiar de un server a otro.

Acerca Los verdaderos programadores no necesitan diagramas :-)

Creo q es verdad pero como se extranan los diagrams cdo estan, te comento esto pq ando desarrollando en javascript q es texto nada mas, nada de drag & drop ect y se puede pero se sufre.


saludos Frank

jueves, enero 10, 2008 7:51:00 p. m.  
Blogger Alfredo Novoa said...

si tienes un potencial cliente q ya tiene oracle comprado o cualquier otro backend el cual no le resulta de interes instalar un nuevo servidor de bd pq ya tiene soporte ect con el q compro pues ese cliente lo pierdes

Pues para mi eso es bastante raro y ocurre sobre todo cuando vendes productos, y por aquí la gran mayoría vende servicios y las cosas se hacen solo para un cliente. Pero si hace falta le regalo el SGBD y le vendo yo el soporte.

Al final servidores decentes hay 3 y con 2 cubres la gran mayoría del mercado. DB2 se suele usar para cosas bastante específicas, así que lo que más queda es SQL Server y Oracle. Usar mySQL para un ERP me parece una locura. Te haces 2 o 3 versiones del script de base de datos y listo. Lo que conviene en estos casos es usar los SP lo menos posible y aprovechar al máximo las características comunes de los 3 SGBD importantes, que son muchas. Las pequeñas diferencias como lo que dices de las fechas te las oculta cualquier framework ligero orientado a SQL como los DataReaders de .Net

SQL es la forma de comunicarte con un SGBD, no tiene sentido ocultarlo con una interfaz de mucho más bajo nivel para luego andar saltándotela por que no sirve. Para eso nos ahorramos el framework y acabamos mucho antes.

Adaptar un script de base de datos a otro SGBD puede no ser trivial, pero seguro que es mucho menos costoso que infrautilizar el SGBD como hacen la mayoría de los que usan los ORM. El ofbiz ese tiene toda la pinta de hacer eso.

Respecto a los diagramas no se que tienen que ver con el drag and drop. Yo hace años que no hago ningún diagrama y no los echo de menos para nada, pero si que creo mis formularios usando drag and drop. Dejé de hacer diagramas por que me di cuenta de que no los consultaba nunca.

jueves, enero 10, 2008 11:24:00 p. m.  
Blogger franklt69 said...

Bueno Alfredo, la vida dira si la idea detras de frameworks como Entity o Eco, tendran o no futuro mi experiencia es q cambio la manera de pensar a la q usaba cuando desarrollaba a golpe de tabla, query y storedprocedure, en fin te concentras mas en resolver la problematica en cuestion q estar pensando en q este campo es key lo usare pa enlazar con x tablas ect..., la curva de aprendizaje fue un poco grande pq es otra manera de desarrollar pero el resultado segun mi experiencia, es q desarrollo mas rapido sobre todos en app bien grandes y se mejora mucho la comunicacion cdo hay varios miembros del team usando los diagramas de clases, el costo es menos perfomance pero no se decrementa de manera q sea para no usar, ni muy notable, el code queda mas entendible para cualquier ser humano y menos bug se comenten.

No significa q critique el desarrollar directo con sql todo el tiempo, para mi es un camino correcto tambien, lo q trato es de compartir la experiencia q he tenido usando esos framework en particular ECO.


saludos Frank

sábado, enero 12, 2008 6:34:00 p. m.  
Blogger Alfredo Novoa said...

Mi experiencia es justo la contraria. Hacer todos los cálculos del sistema en SQL en el servidor (sin usar ningún cursor, por supuesto), hace que el desarrollo sea muchísimo más rápido. Es más, muchas veces soy capaz de programar calculos bastante complejos mientras me van explicando lo que hay que calcular. Hacer eso con un framework de bajo nivel como Eco me parece completamente impensable.

Eso si, al SQL Server se le suelen atragantar un poco las consultas de cientos de líneas, pero normalmente los tiempos son bastante aceptables y luego siempre se puede optimizar con la tranquilidad de saber que no se va a romper nada.

El problema es que conozco a muy poca gente con un nivel suficiente en SQL y el Modelo Relacional como para poder trabajar así. La mayoría se van a hacer los cálculos y las validaciones a pedal en las aplicaciones por que no conocen otra cosa.

domingo, enero 13, 2008 1:06:00 a. m.  
Blogger franklt69 said...

Alfredo estoy de acuerdo quizas ciertas cosas son mas convenientes en el servidor de bd, pero con la intencion de aprender puedes poner algun ejemplo q te venga a la mente de q por ejemplo hacer los calculos q comentas en los framework como entity o eco serian bien dificil?

Realmente lo de poner validaciones de negocio en el server o hacer calculo tambien podria ser debatible pq a veces en negocios q cambian mucho las reglas es conveniente programar estas en la capa intermedia, otra vez entra elcompromiso hacerlo en el server daria mas perfomance pero menos portabilidad a otros db

Ahora por ponerte un ejemplo q me viene a la mente, las relacion 0.* --- 0.* entre tablas o la relacion 1-0.* con la misma tabla, son bastantes faciles de manipular desde estos framework, lo q quiero expresar es q he vistos cosas q simplifican mucho y sencillamente vas directo a la problematica en cuestion y no en mil trucos sql ect para hacer x cosas, en fin q los 2 enfoques pienso q son validos el sql directo siempre seria seguro lo otro es una abstraccion q te permite concentrar mas tus esfuerzo en resolver la problematica en cuestion y no en lidiar con la tecnologia asociada a cada back end o a cada motor, digamos ado.net y mas viendo toda la historia de cambio q ha seguido microsoft con rdo, ado, ado.net ...

saludos Frank

domingo, enero 13, 2008 3:17:00 a. m.  
Blogger Alfredo Novoa said...

puedes poner algun ejemplo q te venga a la mente de q por ejemplo hacer los calculos q comentas en los framework como entity o eco serian bien dificil?

LinQ to Entities es muy parecido a LinQ to SQL con unas cuantas "peoras".

Por ejemplo me viene a la mente que hace poco he reescrito un código de bastantes miles de líneas en Delphi para calcular una contabilidad y lo he convertido todo en una sentencia insert dentro de un SP y solo me han hecho falta unos pocos cientos de líneas de código. Otra cosa parecida me pasó cuando rescribí el código para calcular los piés de los documentos, que se redujo a una vista.

Eso si, escribir 100 líneas de consultas SQL cansa mucho más y lleva más tiempo que escribir 100 líneas en C#, pero aun así la productividad sigue siendo muchísimo mayor trabajando en SQL.

Yo he trabajado de las dos formas. ¿Cuantos pueden decir lo mismo?

Realmente lo de poner validaciones de negocio en el server o hacer calculo tambien podria ser debatible pq a veces en negocios q cambian mucho las reglas es conveniente programar estas en la capa intermedia, otra vez entra elcompromiso hacerlo en el server daria mas perfomance pero menos portabilidad a otros db

Hacerlo en el SGBD también daría mucho menos trabajo, menos probabilidad de errores y más facilidad para las modificaciones. Las ventajas serían abrumadoramente mayores que las desventajas en mi opinión. No entiendo por que a la gente le preocupa tanto la posibilidad de poder cambiar de SGBD. He visto proyectos que han cambiado de lenguaje de programación 5 o 6 veces y siempre han usado el mismo SGBD y no se plantean cambiarlo. A mi me preocupa mucho más poder cambiar de Delphi a C# o a lo que se ponga de moda mañana, con poco esfuerzo, por que seguro que Oracle y SQL Server seguirán allí. Y con los frameworks es mucho peor todavía. Tienen un tiempo de vida todavía muy inferior al de los lenguajes de programación. No me extrañaría nada que dentro de 3 años LinQ to entities estuviese pasado de moda. Eco ya lo está.

Ahora por ponerte un ejemplo q me viene a la mente, las relacion 0.* --- 0.* entre tablas o la relacion 1-0.* con la misma tabla, son bastantes faciles de manipular desde estos framework

Eso también es trivial en SQL, pero esto son manipulaciones de bajísimo nivel y los frameworks esos no dan para mucho más. Tendrías que juntar cientos de estas manipulaciones para hacer algo útil. Con unas pocas líneas de SQL puedes hacer manipulaciones bastante complejas.

Con SQL tienes: proyecciones, juntas, juntas externas, uniones, diferencias, agrupaciones, restricciones, extensiones, renombrados, asignaciones, etc.

Con los lenguajes de programación de aplicaciones imperativos como Java tienes: asignaciones, saltos condicionales y se acabó.

Es evidente cual es el modelo computacional más potente de los 2.

domingo, enero 13, 2008 1:38:00 p. m.  
Blogger Alfredo Novoa said...

veces en negocios q cambian mucho las reglas es conveniente programar estas en la capa intermedia

La capa intermedia es una parte del servidor. Y no hay ningún problema en programarlo todo allí, siempre que tengas como mínimo las mismas facilidades que con SQL. Es decir: juntas, juntas externas, uniones, diferencias, agrupaciones, restricciones, extensiones, renombrados, asignaciones, reglas de integridad declarativas, etc, etc.

domingo, enero 13, 2008 1:52:00 p. m.  
Blogger franklt69 said...

Alfredo con el animo de ver lo q quizas no veo, en razones te basas para ver Eco ya está pasado de moda.

Te pregunto eso pq al contrario veo a ECO digamos insertandose en el IDE de Visual Studio y no solo de Codegear, pq hoy tiene mas prestaciones q el mismo Entity, en fin me gustaria conocer tus razones pq puedes esta viendo cosas q quizas no veo yo.

saludos Frank

domingo, enero 13, 2008 6:26:00 p. m.  
Blogger Alfredo Novoa said...

Esto debería de ser suficiente explicación:

http://www.google.es/trends?q=borland%2C+codegear&ctab=0&geo=all&date=all&sort=0

Probé a poner "Enterprise Core Objects" pero pone que no hay suficientes resultados para pintar un gráfico.

Codegear es una empresa casi irrelevante que da soporte a productos moribundos. Con la tendencia actual, a Borland (su matriz) le quedan menos de 2 años. Que pena que salga solo desde el 2004, por que si viesemos más años se vería un declive mucho más espectacular.

ECO no tiene más prestaciones, tiene más defectos.

domingo, enero 13, 2008 7:32:00 p. m.  
Blogger franklt69 said...

Alfredo, es cierto q borland esta moribunda y eso lo entiendo, y ni es discutible, pero segun he leido ECO hoy es una empresa de Suecia, independiente q produce para codegear IDE y ahora pa visual studio, esos suecos andan en ese mundo de MDA desde 1997 con productos como Bold usado en Delphi, http://www.capableobjects.com/company/aboutus
Lo q quiere decir q no son unos improvisados de momento q esta de moda esos framework, de hecho segun lei el mismo microsoft tuvo varios intentos como object space creo q se llamaba el producto q abortaron ect hasta salir ahora con Entity q aun esta beta.


Lo q quiero es como entender tecnicamente pq lo consideras peor, y la inquietud de veras esta en q yo he trabajado con ECO3, C# Builder y me ha ido bien ahora pienso migrar a Visual Studio 2008 y pienso q no sea muy traumatico pero me gustaria mirar las opiniones acerca de tecnicamente pq pueden considerar Entity superior a Eco Framework, en fin la idea no es decir Entity es de microsoft y es el camino ciegamente, pq de veras es mas seguro ese camino pero hay ciertos productos q son superiores y por no tener la etiqueta de microsoft ni se miran.

De modo q sinceramente te agradezco la advertencia de borland ect pero si tienes algunos temas de peso q me pudieras decir podria ayudarme a evaluar mi salto a visual studio ok

Fijate q ni mi intencion es ni defender a un framwork sobre otro yo conozco algo de ECO y estoy expresando mi experiencia pero si me demuestran q Entity es mejor en x cosas pues seria de gran valor para mi.

saludos Frank

lunes, enero 14, 2008 1:09:00 a. m.  
Blogger Alfredo Novoa said...

No sabía que la gente de ECO había abandonado Codegear, tampoco me extraña.

Yo creo que los frameworks del tipo de ECO son una moda que ya está decayendo por que la gente se va dando cuenta de que no son útiles. Si Microsoft abortó varios intentos fue por que no estaban contentos con como estaba quedando, y no me extraña por que el enfoque está fundamentalmente equivocado.

Tanto ECO como LinQ to Entities están basados en errores garrafales como mezclar tipos (clases) con variables (tablas), pero creo que ECO es mucho más dañino por que promueve la implementación de las reglas de negocio con código procedimental y en cambio LinQ permite hacer programación declarativa directamente desde C#, lo cuál es en principio un gran paso en la dirección correcta, aunque por desgracia la implementación de esa buena idea deja mucho que desear.

martes, enero 15, 2008 1:10:00 p. m.  
Blogger franklt69 said...

Alfredo prodrias darme mas detalles acerca de lo q dices:

ECO es mucho más dañino por que promueve la implementación de las reglas de negocio con código procedimental y en cambio LinQ permite hacer programación declarativa directamente desde C#

Me quedo con dudas, y no se si te refieres a esto, por ejemplo yo he notado esto como algo desventajoso, digamos yo traigo un conjunto de datos del server y necesito actualizar 1 field o attributo de esos datos en ECO despues q tengo todos esos objectos tengo q recorrerlo en un foreach e irlo en memoria actualizando, despues hago un updatedatabase y se actualiza todo en una transacion



Existe en Linq o en Entity un proceso diferente en esos casos?, en SQL usarias el update y en un commando se haria todo, pero mi duda es como maneja esos casos Entity


saludos Frank

martes, enero 15, 2008 3:22:00 p. m.  
Blogger Alfredo Novoa said...

digamos yo traigo un conjunto de datos del server y necesito actualizar 1 field o attributo de esos datos en ECO despues q tengo todos esos objectos tengo q recorrerlo en un foreach e irlo en memoria actualizando, despues hago un updatedatabase y se actualiza todo en una transacion

Si, esto es un ejemplo de lo que se debe evitar. Si quieres actualizar un atributo pues te creas una consulta SQL que le explique al servidor lo que hay que hacer, y se actualiza todo en una sentencia sin traer nada al servidor.

Existe en Linq o en Entity un proceso diferente en esos casos?

Desgraciadamente no, es uno de los fallos más grandes de LinQ, y razón suficiente para descartarlo.

en SQL usarias el update y en un commando se haria todo,

Como tiene que ser.

pero mi duda es como maneja esos casos Entity

Pues prácticamente igual a como has descrito :(

martes, enero 15, 2008 3:55:00 p. m.  
Blogger Alfredo Novoa said...

Sin traer nada del servidor, quería decir.

martes, enero 15, 2008 3:56:00 p. m.  
Blogger franklt69 said...

Me quede realmente con dudas si no es mucho abusar de tu paciencia, q me quisiste decir en:

ECO es mucho más dañino por que promueve la implementación de las reglas de negocio con código procedimental y en cambio LinQ permite hacer programación declarativa directamente desde C#


y ahora me quede confundido tambien, necesita Entity para actualizar un field, traer ese del server, actualizarlo en memoria y despues enviarlo al server? o puede hacerlo sin traerlo?

Sabes si Entity tiene como especie de un debugger q puedas usar en runtime desde la aplicacion cliente, (digams winform)para ver los datos q vas editando, los nuevos q insertas, los q elimine ect, q sql se genero para el backend, en fin pa inspeccionar un poco lo q va haciendo el framework

saludos Frank

martes, enero 15, 2008 7:10:00 p. m.  
Blogger Alfredo Novoa said...

y ahora me quede confundido tambien, necesita Entity para actualizar un field, traer ese del server, actualizarlo en memoria y despues enviarlo al server? o puede hacerlo sin traerlo?

Por lo que tengo entendido hay que traerlo.

Cuando me refería a que permitía programación declarativa me refería a las consultas. Debería de haber dicho: "permite algo de programación declarativa".

De todas formas "Entity" sigue siendo mejor que ECO por que permite actualizar algunas expresiones y no solo tablas.

Sabes si Entity tiene como especie de un debugger q puedas usar en runtime desde la aplicacion cliente, (digams winform)para ver los datos q vas editando, los nuevos q insertas, los q elimine ect, q sql se genero para el backend, en fin pa inspeccionar un poco lo q va haciendo el framework

No lo se.

miércoles, enero 16, 2008 12:49:00 p. m.  
Blogger franklt69 said...

Con la intencion de no ver quien es mejor q quien sino saber q caracteristicas ofrece cada framework puede alguien q haya trabajado con Entity (quizas Alfredo pueda ayudarme) decirme si Entity a su manera ofrece las prestaciones q estan en este Link q ofrece ECO y cuales puede tener Entity q no tenga ECO

http://www.capableobjects.com/products/ecoiv/features

saludos Frank

jueves, enero 17, 2008 3:00:00 p. m.  
Blogger Mikel said...

Hola!!

Conozco CapableObjects desde sus inicios del producto Bold (un producto añadido a la versión empresarial de Borland Delphi), y he desarrollado varias aplicaciones ERP al estilo MDA tanto para escritorio como para Web. Puedo decir que el equipo de CabapableObjets es uno de los mejores al respecto (por experiencia y buen hacer) durante los últimos años, empresa que no se casa ni con Borland, ni Codegear, ni con Microsoft, sino que trabaja por sus objetivos ofreciendo productos compatibles tando para Codegear Studio como los Visual Studio de Microsoft.

Ante la discusión de Alfredo y Frank, debo decir que Frank ha dado continuos argumentos mientras que Alfresdo se escuda en una manera más tradicional de programación, todos sabemos que el SQL funciona, ¿pero qué sucede cuando trabajas con 300 tablas cruzadas?, ¿quién y cómo se mantiene eso después?, para mi el futuro está en diseñar y poder mantener ese diseño después, adelanto que no quiero entrar en discusiones etéreas.

Para acabar, Frank, ¿conoces el Vanatek Open Access? ya que ahora es de Telerik, que también es una empresa que trabaja muy bien, y creo que ahora tienen una versión Community llamada Telerik OpenAccess ORM Express que es gratuita para acceso a Bases de Datos libres (MS SQL Server Express, Oracle Express, MySQL and Firebird). Que por cierto, yo he trabajado mucho con firebird, y es una de las mejores que conozco.

Salu2,
Himikel
Trebea Web Solutions

jueves, enero 29, 2009 12:30:00 p. m.  
Blogger Alfredo Novoa said...

, todos sabemos que el SQL funciona, ¿pero qué sucede cuando trabajas con 300 tablas cruzadas?, ¿quién y cómo se mantiene eso después?

300 tablas es una base de datos mediana que la puede mantener una sola persona sin mayor problema, pero si a las 300 tablas le añadimos 300 clases que no sirven para nada pues entonces las cosas no se vuelven más fáciles precisamente.

Además una base de datos de 300 tablas es muchísimo más fácil de mantener que una aplicación con 300 clases, y la lógica de negocio es muchísimo más fácil de asegurar en la base de datos que en las aplicaciones.

Si seguir principios científicos firmemente establecidos es ser tradicional ¿Que es hacer cosas que se sabe que son desastrosas desde hace décadas como gestionar los datos desde las aplicaciones?

En muchos aspectos, sobre todo en los esenciales, los ORM son mucho más antiguos que lo que llamais "tradicional".

El que no conoce la historia está condenado a repetirla.

jueves, enero 29, 2009 12:54:00 p. m.  
Blogger Mikel said...

Buenas Alfredo y comunidad,

Alfredo, yo no seré el que juzgue lo que sabes o lo que no, me parecería absurdo hacerlo, desconocemos de los conocimientos de los demás, los aciertos y fracasos que haya tenido cada uno, porque si hay algo seguro es que si no admitimos fracasos, es seguro que no habremos aprendido...

Creo que no me has entendido del todo, quizás porque tengamos distinta visión, seguramente por trabajar de distinta manera, te formulo varias preguntas para la reflexión, ¿ crees que un nuevo programador (no el creador) podría mantener esas 200 tablas y relaciones, y hacer modificaciones fiables de una manera sencilla? , ¿ y si en vez de una persona fuese un grupo ?, quizás para tu modelo de trabajo te baste, para una persona que conoce todo el diseño, pero cuando haya que escalar la solución y ampliar el equipo de desarrollo quizás veas ciertas limitaciones de diseño inhentes que tiene esa manera de trabajar. Pero reconozco que para ciertas maneras de trabajar puede llegar a ser muy práctico y efectivo.

Respecto a si conozco las potencialidades del SQL..., pues desde hace más de 15 años, y he desarrollado (y aún lo hago) con aplicaciones de cientos de tablas atacadas con sentencias SQL, Stored Procedures, Triggers y Generadores, Vistas y UDFs (programadas en C++). Todo funciona perfectamente, pero hablemos de su mantenimiento y flexibilidad, ¿ cómo incide en la aplicación o procedimientos almacenados cuando añadimos/alteramos unas cuantas relaciones ?, ¿ y cómo solucionamos sus interdependencias ?, y ni que decir de ampliar herencias...

Por aclarar lo de las clases y su mapeo en tablas, depende de cómo se configure cada clase o incluso del propio ORM, se crearán más o menos tablas, no se porque dices que es más sencillo lo uno o lo otro, en todo caso esto no debería de ser el trabajo de un diseñador-creador de aplicaciones, es como que nos preocupásemos del asembler que genera una instrucción de C++, o las instrucciones Win32 (x86/x64) que generan los métodos en C#.NET, se abstrae y ya está, todo es mucho más fácil.

Para acabar, decirle a cualquiera que haya leído hasta aquí (que tiene su mérito ;-), que opte por la solución más práctica para él, pero que tenga en mente que cuando tenga que escalarlo o integrarlo con otras soluciones quizás no le baste y tenga que buscar otro modo de hacerlo, cada uno verá que le satisface más en cada momento (no existe lo mejor para todo y menos para siempre).

Salu2 Alfredo y comunidad,
seguro que algo hemos parendido en este diaologo ;-)
Himikel
Trebea Web Solutions

jueves, enero 29, 2009 6:35:00 p. m.  
Blogger Alfredo Novoa said...

¿ crees que un nuevo programador (no el creador) podría mantener esas 200 tablas y relaciones, y hacer modificaciones fiables de una manera sencilla?

Depende. Eso es trabajo para un DBA, no para un programador. Si el programador además de programador es un DBA competente no tendrá ningún problema.

Pero ¿Cuál es la alternativa a esto?

¿Usar un ORM que genere una base de datos automáticamente?

Esto es obviamente un desastre por que ese tipo de ORM genera bases de datos pobrísimas. Es como volver a la edad de piedra.

¿ y si en vez de una persona fuese un grupo ?

Pues el grupo de programadores solo tiene que conocer la vista externa de la base de datos. El resto es asunto del DBA o de los DBAs. Así se divide el trabajo y se reduce mucho la complejidad.

Respecto a si conozco las potencialidades del SQL..., pues desde hace más de 15 años, y he desarrollado (y aún lo hago) con aplicaciones de cientos de tablas atacadas con sentencias SQL,

Una cosa no implica la otra, y por las cosas que dices no parece en absoluto que sepas usar bien un SGBD SQL. Para empezar a las tablas no se les ataca.

¿ cómo incide en la aplicación o procedimientos almacenados cuando añadimos/alteramos unas cuantas relaciones ?

Otra vez lo mismo. No incide en nada. ¿Has oido hablar de la independencia lógica del Modelo Relacional?

no se porque dices que es más sencillo lo uno o lo otro, en todo caso esto no debería de ser el trabajo de un diseñador-creador de aplicaciones, es como que nos preocupásemos del asembler que genera una instrucción de C++, o las instrucciones Win32 (x86/x64) que generan los métodos en C#.NET, se abstrae y ya está, todo es mucho más fácil.

Aquí queda muy claro que de conocimientos sobre bases de datos cero patatero. Un SGBD SQL sirve para mucho más que para guardar en disco el estado de una aplicación.

jueves, enero 29, 2009 7:08:00 p. m.  
Blogger Mikel said...

Conozco a unos cuantos profesionales (programadores, analistas, arquitectos) y no creo que ninguno tenga tu osadía a la hora de hacer tales afirmaciones, sólo comentarte que el que es tan tajante pierde capacidad de adaptación, y en esta profesión es imprescindible, todo va cambiando rápidamente, y lo que ayer servía hoy quizás no, ¿te lo has planteado alguna vez?

Te animo a que expongas aquí mismo públicamente tanto tu experiencia profesional como tu larga lista de trabajos exitosos, y de paso me des la receta para ser tan listo...

En su defecto, todo lo anteriormente expuesto quedará en entredicho.

Ante todo salud, y un poco de humildad y respeto.

viernes, enero 30, 2009 1:48:00 a. m.  
Blogger Alfredo Novoa said...

Conozco a unos cuantos profesionales (programadores, analistas, arquitectos) y no creo que ninguno tenga tu osadía a la hora de hacer tales afirmaciones,

Pues yo conozco a algunos de los mayores expertos mundiales en bases de datos, y pocos se molestarían en contestar a tonterías como estas.

sólo comentarte que el que es tan tajante pierde capacidad de adaptación, y en esta profesión es imprescindible, todo va cambiando rápidamente, y lo que ayer servía hoy quizás no, ¿te lo has planteado alguna vez?

Tonterías. Si llega alguien diciendo disparates, se le dicen las cosas como son y ya está. Y si se ofende pues que se hubiese informado un poco antes de abrir la boca.

En el desarrollo de sistemas de bases de datos no ha habido ningún cambio sustancial en décadas, pero aun queda mucha gente que no ha asimilado el Modelo Relacional y sigue gestionando los datos como en los años 50 y 60. Los ORM como ECO son para este tipo de gente, y lo que ayer (hace 40 años) servía y ahora no es gestionar los datos desde las aplicaciones con código procedimental.

Te animo a que expongas aquí mismo públicamente tanto tu experiencia profesional como tu larga lista de trabajos exitosos,

Esta petición es muy impertinente, pero para que no lo uses como excusa, llevo más de una década desarrollando sistemas de bases de datos y de control industrial para empresas desde muy grandes a muy pequeñas y desde un usuario a muchos miles y que afectan a todo el país. Pero nada de esto es relevante cuando se discute sobre cosas que se aprenden en la primera clase de un curso de bases de datos.

y de paso me des la receta para ser tan listo...

Solo hay que molestarse en aprender los fundamentos de la profesión. Algo muy básico.

viernes, enero 30, 2009 3:12:00 a. m.  
Blogger Mikel said...

Impertinente¿?..., quizás lo haya sido un poco ;->>, pero es que tu lenguage es muy directo y al parecer tu sabiduría muy grande, no sabía que eras todo un guru de las bases de datos relacionales, ¡ perdón maestro !

Respecto a los fundamentos de mi profesión, entiendo adquirí mis conocimientos de bases de datos relacionales en los primeros años del 90 cuando estudiaba la asignatura de bases de datos en la uni, y después pensaba que la hábía reforzado durante todos estos años de experiencia profesional, pero quizás no haya avanzado lo suficiente, desde luego es difícil destacar al lado de todo un guru como tú... :-]

Ahora volvamos al tema, una pregunta concreta, ¿ cómo lanzo una consulta de Business Intelligence que relacione diferentes tipos de bases de datos (de diferentes fabricantes) y devuelva un sólo resultado ? ¿ y cómo hago después un análisis de esos datos ?

Te he respondido con cierto cinismo y sentido del humor, para tolerarte un poco mejor ;-)

viernes, enero 30, 2009 9:39:00 a. m.  
Blogger Alfredo Novoa said...

no sabía que eras todo un guru de las bases de datos relacionales

¿Y por qué presupones que no lo soy?

adquirí mis conocimientos de bases de datos relacionales en los primeros años del 90 cuando estudiaba la asignatura de bases de datos en la uni, y después pensaba que la hábía reforzado durante todos estos años de experiencia profesional

No te fíes mucho de eso. En la universidad se suelen enseñar bastante mal esas cosas. Trabajando no se aprende teoría y si no la refrescas, la poca que se aprende en la universidad se olvida. Se aprende estudiando buenos libros y de esos hay muy pocos. Si quieres te recomiendo alguno.

¿ cómo lanzo una consulta de Business Intelligence que relacione diferentes tipos de bases de datos (de diferentes fabricantes) y devuelva un sólo resultado ? ¿ y cómo hago después un análisis de esos datos ?

Pues lo normal es que un DBA experto diseñe un "datawarehouse" y que programe servicios de transformación de datos DTS para mantenerlo actualizado. Una vez hecho esto los programadores ya pueden utilizar SQL para hacer las consultas que necesitan.

Otra opción es usar un producto del tipo de IBM InfoSphere Federation Server que te permite combinar diferentes bases de datos de diferentes fabricantes y verlas como si fuesen una sola base de datos.

Lo que no se es que tiene que ver esto con ECO.

viernes, enero 30, 2009 1:51:00 p. m.  
Blogger Mikel said...

Buenas Alfredo & comunidad,

No tengo dudas en que las herramientas que utilizas sean buenas, pero hoy día hay que considerar todos los costos que tiene asociados el utilizar una u otra solución, y existen innumerables opciones para ello. Si a ti y a tu equipo os va bien con ellas, adelante, nada que objetar.

Para el que tenga la curiosidad de conocer toda la potencialidad que tiene el FrameWork ECO, le recomiendo que vea la siguiente presentación:

ECO: The Framework Argument

Ahora no voy a entrar a hacer un estudio, ni un análisis comparativo entre diferentes soluciones, para ello están los que tienen interés comercial en ello (que obviamente no es mi caso).
Para acabar, lo dicho antes Alfredo, elige las herramientas que mejor te vayan para cada caso, pero no te cierres demasiado, si no quieres perder prespectiva ;-)

Salu2!!
Himikel
Trebea Web Solutions

miércoles, febrero 04, 2009 12:17:00 a. m.  
Blogger Marco Antonio said...

Primeramente saludos a todos.

Existe mucha polémica de si es bueno o no EF (Entity Framework ) , LinQ, Etc …. Comparto algo de mi experiencia y problemáticas con las que me he topado.

Con respecto a la temática de Entity Framework, LinQ, LinQ to SQL, son temas realmente extensos y ya llevo unos meses metiéndome en la temática de como poder hacer una mejor optimización del sistema de control de acceso y realmente utilizando:

*LINQ con DataSet
Es una herramienta que me ha ayudado en obtener información que posiblemente me ahorro una que otra consulta o transacción en el servidor, dirán que por qué no realizo un SP y ya, pero en ocasiones por las políticas de la empresa tenemos que se procese el resultset en memoria de la aplicación (ya saben siempre hay que vender las actualizaciones) , claro que habrá uno que otro SP que si liberamos pero ya es cuestión de performance de la aplicación.

Si por mi fuera realizaría los cálculos y operaciones en el servidor y claro ahorraría mucho tiempo de trabajo, pero ya teniendo el ResultSet en mi DS o DT ya es una gran ventaja el LINQ.

jueves, febrero 11, 2010 6:55:00 p. m.  
Blogger Marco Antonio said...

*Entity Framework

Tratando de explotarlo para hacer el performance de una aplicación de control de acceso la cual constantemente está presentando información y tiene una gran cantidad de relaciones (Puertas, Paneles,Horarios,Perfiles,Botones,usuarios, credenciales, etc….) y realmente tiene querys un tanto complejos.

Al realizar un mapeo de la base de datos del control de acceso y genera los querys habituales para EF(Entity Framework) ya sea en QueryObject o LinQ , si te cambia el panorama de las consultas y las cónsulas que tanto estamos acostumbrados a realizar cambian por el hecho del mapeo que te realiza. Se me hizo un tanto tedioso reajustar los querys pero los hice, lo cual no me gusto en su totalidad al final me tarde mas hacer que el Query funcionara como debían de ser y de hecho en varios casos la lógica de EF o LinQ en el parseo no es tan acertada, por que lo digo por que rastreando en SQL Profile como hace la conversión a Transact me doy cuenta que sin Foreing keys, tus Joins siempre serán el clásico “Inner Join” y con Foreignk Keys no todos los “Left Joins” que requieres son presentados(eso para el software de acceso es realmente malo ya que hay casos que realmente ocupas el left) y ni se diga que tienes que hacer un Interprete Anonimo para cada query compilado que venga con un Join =S.

Ahora también queda la posibilidad de usarlo con un QueryObject y realizas el query casi igual que en SQL solo que apegándote al mapeo realizado en tu archivo EDMX, pero oh gran problema por que toda relación con JOINS tienen que ser relacionadas no con el campo de la tabla1 con la tabla 2 sino haciendo referencia al FK establecido, asi que ahí les encargo andar modificando el query para que funcione igual, y claro funcionara pero ya es una inversión de tiempo.

Me atrajo la idea del EF pero tengan en cuenta esto, en el trabajo lo principal es el perfomance de al aplicación, principalmente que funcione y los tiempos de entrega, cuánto tiempo crees que te meterás en hacer un query en EF o LinQ que funcione como tu realmente quieres y cuanto tiempo te meterás en hacerlo en SQL, tomen en cuenta que en ocasiones hay problemas que tienen que resolverse en ese mismo instante o ahora si aplicamos lo de “o se soluciona o traigo a alguien que si pueda”, no niego que si lo tienes muy bien afinado será una chulada pero nosotros como desarrolladores sabemos que el cliente quiere milagros y para el cliente siempre será un “agrégale un IF y ya con eso funciona … que tan difícil es”… pero realmente siempre trabajamos con aplicaciones que parece que trabajamos con los palillos chinos mueves uno y se te mueve todoooo esto en ocasiones.

pero no todo es malo, ya que en consultas sencillas directamente a una tabla funciona muy bien y no existe problema alguno de acuerdo a traer una gran cantidad de información.

jueves, febrero 11, 2010 6:55:00 p. m.  
Blogger Marco Antonio said...

*Porque me intención de utilizar Entity Framework

Por el hecho que muchos de los clientes que tenemos están casados con SQL y de acuerdo a varias pruebas e investigaciones Entity Framework + LinQ con Querys Compilados mejor mucho el tiempo de consulta y la presentación de la información, esto claro en con una concurrencia mínima ya que si lo ponemos en una concurrencia habitual de N acceso por segundo posiblemente tenga una respuesta lenta.

Pero tratando de hacer un poco de conciencia de la mentalidad de Microsoft, todos sus ejemplos son sencillos , básicos y sin complejidad alguna a mi parecer con temor a equivocarme creo que ellos también presentan la misma problemática que muchos al querer presentar resultados con querys complejos, pero bueno esta es mi humilde opinión, cada quien tendrá la suya y la respeto.

*Conclusión:

Linq +[ DataSet | DataTable|IEnumerables]
Ventajas
Ahorro de tiempo en obtención de resultados

Desventajas
Puede resultar al principio un tanto difícil comprenderlo


Entity Framework
Ventajas
Trabajar directamente con la BD
Fácil al realizar Insert, Update o Delete
Consultas rápidas

Desventajas
Primer consulta algo lenta
No cuenta con CopyToDatatable
Problemas al realizar querys complejos



Una vez as esta es mi humilde opinión y aun estoy en la cruzada de realizar el performance del sistema de control de acceso.

Saludos.

jueves, febrero 11, 2010 6:56:00 p. m.  
Blogger Alfredo Novoa said...

Cuando empecé a leer sobre el EF no me gustó nada y me pareció una tontería. Ahora llevo un tiempo usándolo en un proyecto real y mi opinión ha cambiado: es una basura total. Un trabajo de subnormales.

No se pueden actualizar las vistas. Cada vez que cambias algo en la base de datos tienes que borrar el modelo y volverlo a crear perdiendo todas las personalizaciones. Ni siquiera es sencillo ejecutar procedimientos almacenados. No se puede acceder a los nuevos tipos de datos de SQL Server. Algunas tablas desaparecen porque la porquería esa decide que no son tablas sino relaciones. Si la base de datos no está como a él le gusta no es capaz de generar el modelo, y así un sin fin de cagadas.

Estoy totalmente arrepentido de haberlo probado, estoy en proceso de eliminarlo de la aplicación.

viernes, febrero 12, 2010 11:37:00 a. m.  

Publicar un comentario

<< Home