2008-10-03 15 views
21

¿Cuál es la principal diferencia entre LINQ vinculable y LINQ continuo?LINQ vinculable frente a LINQ continuo

• Bindable LINQ: www.codeplex.com/bindablelinq

• LINQ Continuo: www.codeplex.com/clinq se añadió

un proyecto más basándose en la información proporcionada:

• Obtics: obtics.codeplex.com

+2

Nice! No tenía idea de que existiera tal cosa. Gracias por llamar mi atención alex. :-) – mezoid

+0

Después de considerar estos tres proyectos, decidí continuar desarrollando [mi propia solución] (http://happynomad121.blogspot.com/2013/01/data-binding-among-complex-expressions.html) ya que me permite escribir consultas puras de LINQ-a-Objetos, sin modificaciones, como siempre lo hacía antes. – HappyNomad

Respuesta

25

Hay dos problemas que estos dos paquetes intentan resolver: Falta de un evento CollectionChanged y conjuntos de resultados dinámicos. Hay un problema adicional de soluciones enlazables, activadores de eventos automáticos adicionales.


El primer problema ambos paquetes tienen como objetivo resolver es la siguiente:

objetos devueltos por una consulta LINQ hacen no proporciona eventos CollectionChanged.

continua LINQ hace automáticamente a todas las consultas, sin cambios:

from item in theSource select item ; 

Bindable LINQ tiene esto cuando agrega .asBindable a su consulta de origen del objeto:

from item in theSource.AsBindable() select item ; 

El segundo problema ambos paquetes tienen como objetivo resolver es:

conjuntos de resultados devueltos de una consulta LINQ son estáticas.

Normalmente cuando se hace una consulta de LINQ el resultado conjunto es sin cambios hasta que lo haga una nueva consulta. Con estos dos paquetes, su conjunto de resultados se actualiza cada vez que se actualiza la fuente . (Malo para el rendimiento, buena para actualizaciones en tiempo real)

Ejemplo

var theSource = new ContinuousCollection<Customer>(); 
var theResultSet = from item in theSource where item.Age > 25 select item; 
//theResultSet.Count would equal 0. 

Debido a que su uso de Bindable o LINQ Continuo, que podrían modificar theSource y theResultSet incluiría automáticamente el nuevo elemento.

theSource.Add(new Customer("Bob", "Barker" , 35, Gender.Male)); //Age == 35 
//theResultSet.Count would now equal 1. 

el problema adicional Bindable LINQ ofrece: (Citando directamente de su propia página)

contactsListBox.ItemsSource = from c in customers 
           where c.Name.StartsWith(textBox1.Text) 
           select c; 

Bindable LINQ detectará que la consulta se basa en la propiedad Text el objeto TextBox, textBox1. Desde el TextBox es un control WPF, Bindable LINQ sabe suscribirse al evento TextChanged en el control.

el resultado final es que a medida que el usuario se tipos, los elementos de la consulta son re-evaluados y los cambios aparecen en pantalla. No se necesita ningún código adicional para manejar eventos.

4

Otra cosa a tener en cuenta, aunque BindableLinq requiere la llamada ".AsBindable()" de la cuenta de LINQ, CLINQ requiere el uso de ContinuousCollection < T> en lugar de ObservableCollection < T>. Después de mirar ambos brevemente, creo que voy a ir con LINQ vinculable.

4

De hecho; el problema principal con Continuous LINQ es la imposibilidad de utilizar cualquier colección que implemente los IEnumerables genéricos e INotifyCollectionChanged. Bindable LINQ no tiene ningún problema con el uso de colecciones personalizadas que implementen las dos interfaces.

5

¿Puedo llamar su atención sobre otro proyecto codeplex? Se llama Obtics y trata los mismos problemas (http://obtics.codeplex.com).

Soluciona tanto el primero como el segundo y el problema adicional y lleva la reactividad a un nivel muy profundo (tiene una demostración con un raytracer basado en LINQ).

Reclama soporte completo para todas las declaraciones LINQ y métodos de la clase Enumerable.

Se utiliza otro mecanismo para crear consultas en directo:

var theResultSet = ExpressionObserver.Execute(
    () => from item in theSource where item.Age > 25 select item 
).Cascade(); 
+1

Acabo de probar esto, y parece que la reevaluación deResultSet hace que theSource vuelva a enumerarse, por lo que no está resolviendo El segundo problema como se describió anteriormente. Mi metodología podría estar equivocada, supongo ... – mcintyre321

1

Uso enlazable LINQ, ya que implementa IDisposable, y por lo tanto se puede controlar cuando una consulta se dispone. Cuando lo deseche, todas las suscripciones a INotifyPropertyChanged se cancelarán.

Continuo LINQ se supone que resuelve este problema con eventos débiles, pero no funciona tan lejos como pude probar.

Hmm ... esto parece ser un problema con LINQ enlazable (la segunda aserción falla):

var _source = CreateSource_6People(); //(David, 27), (Mark, 15), (Steve, 30), (Jordan, 43), (Shiva, 30), (Erb, 43) 
IBindable<int> bindable = _source.AsBindable().Sum(x => x.Age); 
var agesSum = 27+15+30+43+30+43; 
Assert.AreEqual(agesSum, bindable.Current); //PASSES 

_source[0].Age += 1; 
Assert.AreEqual(agesSum + 1, bindable.Current); //FAILS... DISAPPOINTING