WPF Linq to SQL applications Some Best practices using binding and master/detail views

Question

Hi, Well i feel im missing something here because im having problems i bet a bunch of people ran into before and i cant find any solutions to this simple scenario.

Application Technology:

WPF, 3.5(sp1) framework, LINQ to SQL, o/r designer CRUD, Visual studio 2008, C#.

Apllication Layout:

Main layout conatins a panel to the left holding listboxes that are generated bound to linq to sql entities (to the view of the ToList() method of the entites), buttons under the list allow you to add / delete / edit and also contains text filter for the items. if you choose to edit / add a new window opens up besides the original panel and its a master / detail view form, the items in this form are bounded through XAML with a CollectionViewSource.

My expieriences:

1. When adding elements to the Master Detail form there is too much play with the datacontext that was auto generated my the O/R designer, calls to InsertOnSubmit() and DeleteOnSubmit(), and at the end SubmitChnages().

2. The reason for 1 as well is, i try to use ObservebleCollections wereever i can to wrap the linq etities ToList() IList, because otherwise i am not able to filter the results easily in memory and Bind the items. If BindingListCollectionView implementation through linq to sql entites allowed filtering that would pretty much make my day.

3. When i create a new Master / Detail view i pass the original ObservableCollection and crate a new view for it (mainly because i use XAML to bind the form, and to cut down on code) when a new item is added the original list in the panel window doesnt shows the item, but the list doesnt get re sorted and indexes get screwd up.

4. When i try to use Enitites that are relationships in my database and are defined as EntitySet in the O/R designer generated crud, i am forced to use the returned BindingListCollectionView which is not filterable (see #2), the only way i found around this is actually to query the relationships myslef and force them into QbservableCollections as well, this increses loading time and is cumbersome since all the eneties now need specific ObservableCollection wrapers and not a generic one.

5. When using named styles there are querks i just cant figure out forinstance

   <Style x:Key="MainTheme" >
   <Setter Property="CheckBox.Foreground" Value="#333333" />
   <Setter Property="TextBlock.Foreground" Value="#333333" />
   

   Above style set on the top level contain in a page would set all the textblocks the correct forgound color but would have no effect on checkboxes, checkboxes would need to have a specific style="" property set to that style and only then work.

So far i get the felling ethier im doing some things horribly worng or most of these technologies arent really as mature as i first thought they are, anyone able to help with any of these issues or just provide a Best Practice for what i want to achive (defined in the application layout par at the top) i humbly request your help.

Thanks, Eric.

Answer 1

Hello,

I agree with you. I'm wondering if the new ADO.NET Entity Model would solve these problems. Do you have any experience with ADO? Can DataSet solve the collection changed notification problems from LINQ to SQL and Entity Model?