WPF and seperation of concerns
I have migrated from WinForms to WPF. I've written my latest desktop programs in it. At first, I didn't like it, except it's grown on me. I like it and have nothing bad to say about it overall. There is one thing however. I keep hearing about how it promotes drastically better separation of concerns than WinForms. In fact, it was one of the things that drew me to the platform.
To me it still seems like the same UI project, DataAccess project, Business Logic project, and Base UI project (UI type-specific data validation and logic) for at least most small to medium scale applications. I no longer need a seperate Entities project because I have now decided to combine that with my Database project because of LINQ, except that has nothing to do with WinForms vs. WPF. I see the XAML file as no different than the old Designer.cs file. It's a bunch of UI objects that shouldn't have anything to do with the Database or Business Logic Layer anyhow. I've always felt that the biggest reason we struggle with separation of concerns with WinForms is because of the forms programming model itself. I remember when I first learned PC programming, even though I certainly preferred VB Forms (pre .NET) over C++ because of productivity, it always seemed that it was a constant battle to discipline myself in order to prevent huge code behinds. Some obvious things, like refusing to ever allow a reference to System.Data.SqlClient to a UI project etc. help. I've always found it more difficult to offload the Logic out of the code behind, but it can be done with enough work. However, I still consider that to be the biggest thing I don't like about Forms programming. It always bothered me that when I got done, my code behinds looked a bit too large. I guess it's a sacrifice for the productivity that forms programming can provide.
I don't understand what XAML does to prevent this and I don't see how tediously typing up XAML is any more "declarative programming" than dragging text-boxes around on a WYSIWYG editor. My programs look a little prettier, except they're still basically the same program. They seem to actually load a little slower as well. My guess on that is that typical business applications written by your average programmer probably don't use enough bells and whistles to take advantage of the superior hardware acceleration of WPF.
Re: WPF and seperation of concerns
Neither WPF nor WinForms enforces any sort of design pattern or separation of concerns approach.
It's up to the developer to enforce.