The principles of great UI design start from a different place than the principles that lead to great application design. They both end up in exactly the same place, though.
The best thing you can do in order to create a great UI is to stop thinking about UI design.
You can completely disconnect your test code from your database with Entity Framework 6 in .NET and Visual Studio. You just need a little bit of custom code for your application, along with some boilerplate code.
Thinking in terms of layers or tiers really isn't much help to you. Stop doing it: The single responsibility principle and design patterns are all you really need.
Prune your Entity Framework with the help of asynchronous methods.
Entity Framework 6 gives you a variety of ways to call stored procedures that return data and capture the results those procedures return. Here's a look at all of them.
When you implement the Model-View-ViewModel pattern you need to tell your View (in this case, a Windows Form) when the ViewModel has new data. Here's how to do that, along with a warning about how to avoid a potential bug.
Peter Vogel moves a Windows Form to a modern design pattern, which forces him to think about how his code should be divided up among his classes. In the end, he comes up with some rules for making those decisions.
Even in a Code First environment, you can call a stored procedure from a DbContext object. But it's a lot easier if you use the visual designer.
Complex Types let you reuse structures in your database design. But unless you've been very lucky around the names in your database, you probably couldn't use Complex Types -- until Entity Framework 6, that is.
The latest version of Entity Framework makes it easier to write asynchronous code. Here's how to write that code, and more important, where you'll actually find it useful.
The latest version of the technology works fine with the Microsoft .NET Framework 4 and Visual Studio 2010. Here's some of what's new (along with how to move your applications to EF6).
Peter wraps up his look at offloading processing from the mainline of your application in order to improve response time by looking at processing message queues asynchronously.
Defining constants in your application is a good thing. But if you understand constants you can also decide when you don't need to use them, how to name them, when to set up exceptions to your names and -- the best thing -- when to replace them with parameters.
If you're using MSMQ to offload work from your Web site, you have a number of ways to pick up those messages, including processing those messages as soon as they turn up.