I've been seeing a growing number of discussions and resources that try to reconcile Microsoft RAD tool output with generally accepted software engineering "best practices" (Separation of Concerns, Inversion of Control etc.). The topic certainly isn't new, but the discussion seems less academic and more mainstream now, compared with the days when Allen Holub would rail against MFC's violation of OOD principles, possibly due to a spreading awareness of Agile and Domain Driven Design principles.
A recently published book, "Microsoft .Net: Architecting Applications for the Enterprise", by Dino Esposito and Andrea Saltarello is almost a definitive reference on this subject, describing Microsoft technologies, from the much-abused Dataset to the recently-maligned Entity Framework, in the context of architecture patterns listed in Martin Fowler's classic "Patterns of Enterprise Application Architecture", while providing practical advice on when and how to apply various approaches on real world projects. The book also does a great job tracing the evolution of the MVC pattern, through MVP "Passive View" and "Supervising Controller" variations, to its current instantiation as the Model-View-ViewModel pattern targeting WPF. The book even includes discussion of the potential benefits of popular NON-Microsoft offerings, including NHibernate.
Other recent examples of discussion in this area include a Code magazine article by Miguel A. Castro, "WCF the Manual Way... the Right Way", describing shortcomings of the "Add Service Reference" option and default code generated by WCF project templates (others have voiced similar criticisms). There have also been a number of variations on how to better segregate data access concerns through some form of generic "Repository" layer. The recent posting of a "Vote of No Confidence" petition (signed by a number of Microsoft MVPs), following the release of version 1.0 of the Entity Framework is, in some sense, a reaction to "convenience" tools that some developers feel make it unecessarily hard to "do the right thing", and may lead inexperienced developers down an inappropriate path. In this case, the Entity Framework team responded with changes to elements of the design planned for version 2.0, commited themselves to soliciting community feedback on an ongoing basis and, most reassuring of all, began consulting directly with DDD/OOD luminaries Eric Evans and Martin Fowler.
The competing M-V-XYZ "schools of thought" all share in the fact that they represent a recommendation to RESIST practices that Microsoft's tool set and documentation encourage by default (placing implementation logic directly in event handlers in the view's code-behind). Whether you'll actually succeeed in getting your project dev. team members to reject IDE features that support the standard project workflow, to manually insert some M-V-Poo mini-framework, is open to question, especially since several of the most popular M-V-XYZ variations rely on advanced WPF features, like custom attached properties, to replace operations as basic as handling a simple ListBox selection change event.
Unlike diatribes against Microsoft technologies that were common years ago, those raising objections today tend to be hardcore FANS of Microsoft technologies. The most influential advocates also tend to be pragmatists, repeatedly warning developers not to become overly obsessed with issues of design "purity". On projects of limited scope, one-click "it just works" solutions that generate a little cross-concern "contamination" may be a perfectly reasonable and practical approach. A product catalog, for example, requiring basic CRUD and query operations with little or no associated business logic, might be a good candidate for binding a Dataset directly to a DataGrid, or making use of the "Add Service Reference" project option although, technically, those approaches represent an inappropriate surfacing of service connection and data storage details in the UI layer.
The work of Microsoft's "Patterns and Practices Group" is supposed to represent "best practice" guidance in applying Microsoft technologies, but that group is not well known outside the ranks of the already-converted, and incorporating their libraries on a shipping product can meet with some resistance, since these aren't regarded as "full-fledged Microsoft product offerings. PAG guidance is not reflected in the standard Microsoft tool set or mentioned in mainstream Microsoft presentations or sample code, leading to a natural reaction along the lines of "If this is so good, how come I've never heard of it, and why isn't it built into Visual Studio?". The PAG group also tends to cripple their own cause, with a wide selection of offerings that seem to be in perpetual beta, and are often intimidating in their complexity ("Composite Application Guidance for WPF", for example, which members of a development team are apparently expected to tackle IN ADDITION to the already non-trivial task of understanding the underlying framework technologies).
Its currently not uncommon for Microsoft resources to describe a technology exclusively in terms of clicking this (Visual Studio) button, and pulling that lever... while highly-regarded developer community resources (Juval Lowy on WCF, for example), explicitly warn against relying on those same conveniences. Just as Microsoft earlier managed to commit to making security a first order concern in all its internal development activity, it could also help make it easy for developers to "do the right thing" BY DEFAULT, by requiring all Microsoft tools, and public-facing materials, sample code, and presentations... to always take "best practice" conventions into consideration. Ironically, the very developers Microsoft is targeting with its RAD tools are the same ones who most desperately need guidance and assistance in learning to write BETTER code -- who are effectively being led down a blind alley, with other developers left to clean up behind them, and try to explain why some code needs to be restructured when "that's the way Microsoft said to do it".