LightSpeed and WPF

Hello,

I started LightSpeed evaluation, and so far it looks rather promising. One thing I am completely lacking (or am I simply blind?) is some resources that would show how to use LightSpeed in WPF applications in most efficient way, kind of How-Tos and/or Best Practices.

Examples of topics could be: Should there be one UoW or multiple? How to show data in lists in a way that would allow the view to be updated if records are inserted or deleted? And so on, and so on...

Of course, one might eventually figure those out by himself, but it would really simplify our lives in case MindScape gurus would explain their view on these topics, especially that they definitely have something to say on them (I would guess ).

Thank you very much in advance.

Best regards,
Roman

Hello Roman, 

Sorry about the slow reply on this.  We don't currently have any samples or documentation specific to WPF, though we're hoping to extract a sample from some work currently in progress.

To pick up your specific questions:

* In general we recommend short-lived units of work, so that the data is always fresh.  However, in a smart client, and if there is minimal risk of contention (i.e. it is unlikely that two people will be working with the same data at the same time), then a single long-lived unit of work can be a lot easier to work with.  You can also use nested units of work.

* EntityCollection implements the IBindingList interface, so adding items to or removing items from a collection should update any controls which are binding to that collection.  (I have a feeling that IBindingList support was added to WPF in .NET 3.0 SP1, so this may not work on 3.0 RTM.)  One thing to watch out for here though is that IUnitOfWork.Find() returns an IList, *not* an EntityCollection/IBindingList -- so if you are adding or removing top-level entities and want to bind to that top-level list then you will need to wrap the Find results in an ObservableCollection, and hook the CollectionChanged event so that as you add entities to and remove entities from the ObservableCollection, they are added to and removed from the unit of work.

* You may need to be a bit careful about what happens if an object's parent is changed, either by setting the parent backreference property, or by removing it from one parent's children collection and adding it to another's.  LightSpeed raises the appropriate property change notifications from the child object, and collection changed notifications from the old and new parent collections.  This shouldn't be a problem if you're binding directly to the LightSpeed model, but if you have a view model or presenter between the LightSpeed model and the UI, then you need to be careful about cascading updates.  (We ran into this when we needed a view model in order to add display positioning data to the "real" model.)

Please feel free to raise further questions, and keep chasing us for the guidance if we don't announce anything in the next two or three weeks. 

better late than never ;-)

@Roman

Call it UnitOfWork or Singleton pattern.

Wether you use a ORM having ONE context or pure SQL having ONE connection. 

All is best practice imho if you develop a single threaded application.

Open the connection at application startup, keep the connection open doing database operations and

close the connection or dispose the context when the application is closing.

The sample I forgot...:

public class DataAccess

    {

        private static UnitOfWork _uow = null;

        private DataAccess() { }

        public static UnitOfWork UOW

        {

            get

            {

                if (_uow == null)               

                    _uow = new UnitOfWork();     

                return _uow;

            } 

         }

    }

Singleton pattern because there is only a single connection/unitOfWork/Responsibility...

ah again something I forgot... today is not my day...

call the UOW this way in your repository classes:

DataAccess.UOW.Context.DoCRUDOperationsLikeDeleteAddEtc... :)

this way I did it with Entity Framework v1 and had no problem with a single threaded app.