>>>>>>>>>>>>>>Hi
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>I'm trying to find some good examples of WPF applications. Development walkthroughs etc
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>Something that involves data access.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>Any recommendations.
>>>>>>>>>>>>>
>>>>>>>>>>>>>Hi,
>>>>>>>>>>>>>Maybe something here: http://www.actiprosoftware.com/Support/ResourceGuides/WPF/ViewCategory.aspx?ResourceGuideCategoryID=26
>>>>>>>>>>>>>
>>>>>>>>>>>>>But, to me, the problem with most WPF samples is that they tend to favour showing off the clever UI stuff rather than demonstrating simple 'ground up' examples
>>>>>>>>>>>>
>>>>>>>>>>>>Yes thats what I'm finding.
>>>>>>>>>>>>
>>>>>>>>>>>>I may just put it to one side till vs2010 as I can't believe how long winded the data access is.
>>>>>>>>>>>In what way 'long-winded'? WPF uses the same NET data access classes as a WinForms or ASP.NET app.......
>>>>>>>>>>
>>>>>>>>>>I can't drag and drop data controls onto a form.
>>>>>>>>>
>>>>>>>>>Something is wrong then, I just tested in a new WPF simple application from scratch and dropped a few controls (generic vs controls, not infragistics) on a window...
>>>>>>>>
>>>>>>>>I think Nick was referring to the Winforms ability to drag fields from a datasource and have the relevant control created and databound automatically (something that's slated for WPF in VS2010)
>>>>>>>
>>>>>>>Yep
>>>>>>
>>>>>>Oh, I don't bind data that way so I wouldn't even notice. :( Sorry Nick.
>>>>>
>>>>>No problem .
>>>>>
>>>>>Do you see that as an inferior way of working ?
>>>>
>>>>It may depend on the app but it's close-coupling the UI to the backend which is not usually a good idea....
>>>
>>>Nicely worded :o)
>>
>>Would you care to enumerate how de-coupling has benefited where you are. And how much that extra layer of obsfucation has cost to develop. :-)
>
>Right off the top of my head, it allows us to work on individual layers, create new forms or modules without worrying about the business or mappers or contracts. We create extensions to the controls to use our own entities and simply set those to 'wire up' the data. If you need to create a new form for example, you simply design it, throw the controls on it, set the control's business and entity props, and we have all of the base functionality in place already so it looks and behaves like others and the data is available. The only thing left to do is any special coding. We only have to add to separate layers (business or mappers) if new rules apply or we are actually adding backend tables. We can throw each layer on any server (or local machine) we wish for the greatest speed enhancement, and we can make changes to one assembly and not have to deploy all of the others. If we want to enable one area for a 3rd party we simply provide a service contract for it which is the same for internal services/messages/modules as well (if SOA is a consideration for you). We can change the backend type (Oracle or SQL Server) easily without rewiring or coding. Just too much to list...

In 30 years I can count the number of times the back end has changed without it being part of a complete re write on the fingers on my left foot. :-)