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.
Visual Studio 2013, with the latest version of TypeScript, gives you the same kind of support you've come to expect when writing code in C# and Visual Basic.
Sometimes you can improve your application's response time by shunting some activities to offline processing -- sending an e-mail response, for instance. Here's how to use Microsoft Message Queue (available on both your development and production computers) to simplify the process.
There are numerous ways to implement a fluent API, depending on the degree of control you want to maintain over the API, how many classes you want to be able to use it with, and how you want to extend your API. Here are your options.
Bryan Freeman's book on creating asynchronous applications does a great job of explaining the technology the .NET Framework provides for creating asynchronous applications.
Just because your language can do it, it doesn't mean that you should.
You can't "grow" a fluent API; you need to understand how developers will need (and expect) to use your API. Here's a case study of what the design process for a fluent API looks like.
Peter continues to look at the value of imposing naming conventions on developers; but this time, he looks at the benefits related to understanding the business problem, as well as why flexibility is crucial.
Here's how to implement a fluent API for a single class that supports the goals of fluent interfaces.
Just because you've created an application, it may not need a user manual, guide or help system. And, even when your application does need that kind of support, you should -- at all costs -- avoid writing it.
Fluent methods are a hot design idea and they can improve the readability of your code. However, they only make sense in specific scenarios. Here are some criteria to help you decide if you should be creating a fluent interface, and some design guidelines for when you do.
Peter returns to the topic of managing multiple users accessing the same row in a table using Entity Framework, but this time using code-first development. There are some unexpected issues to deal with.