Best Practice for Read Only Data

 Hi, I'm just getting started with lightspeed and am getting comfortable with the CRUD operations within a unit of work. 

One question I have is what container is  best to load a WPF  chart or tree control.  In both cases, there is no need to edit the data so I am trying to use the lightest binding source possible.  I have experimented with IEnumerable,List and Entity Collections using the Lightspeed unit of work .   I have also tried getting the data AsEnumerable() directly from the unit of work as well as looping through the linq query to fill the various collections.  I can get the data to load in the control no problem but it seems to be quite slow in some cases (not in filling the container but in processing within the control).

With so many choices, I was wondering if the is any example/pattern recommended as a best practice for loading large read only collections into controls using lightspeed.

Specifically, What collection type is best for read only binding to controls.Within the selected container type, can I expect any performance benefit from using a lightweight class with just properties (mirroring the Lightspeed Entity class) rather than using the Lightspeed generated Entity directly? 

Thanks for your  help.

In terms of a container, a List<T> or ReadOnlyCollection<T> is probably the lightest weight, but an EntityCollection shouldn't incur significant overhead in the read-only case.  A LINQ query typically ends up returning a List under the covers, so that should have similar performance, provided you iterate it only once.  I'm not sure about enumerating over the unit of work, but that could be more expensive -- depends on the underlying performance characteristics of the .NET dictionary type, which I haven't looked into -- and is definitely less clear.

In terms of entities vs. projected types, entities generally incur a size overhead, but should not incur a significant performance overhead in read-only cases.  You could of course easily do a quick test using a LINQ projection (Select) to convert the entities into anonymous types.  One possibility is that the tree is trying to load associated entities: if this is happening lazily then you could be hitting an n+1 query problem which you could address using eager loading.  It's also possible that the control is invoking IEditableObject.BeginEdit, which has an overhead as the entity needs to back up its current values, which is of course pointless in the read-only case.

A handy tip may be to turn on LightSpeed logging -- then you can see if the use of the entities is incurring excessive database queries.

If none of this helps then we would be interested to see a simple repro to try to investigate -- thanks!