The CQRS pattern separates updates from queries, allowing you to create the best process for each of those activities. Effectively, CQRS codifies the standard practice for ASP.NET MVC developers: Here are some strategies for implementing that pattern and improving your application's performance.
If you ever need to work with all of the properties in some object, you can use GetType and GetProperties to retrieve the object's PropertyInfo objects. After that you can do what you want. Here's an extension method that sets all those properties to their defaults, for example.
Data retrieval and updates are very different activities so the CQRS pattern says that the smart thing to do is treat them differently. Here's a variety of solutions for the retrieval side in an ASP.NET MVC application.
You can't make a complicated problem simple. But, by leveraging the right tools in your language (and the Visitor pattern) you can ensure that your code doesn't get as complicated as your problem.
Leveraging the right combination of object-oriented tools can keep your code simple, even as the problems you solve get more complicated.
The ConcurrentDictionary provides the most efficient (and safest) way to shared named values between asynchronous processes with several powerful methods. But the best advice might be to avoid ever needing them.
Using the Stream objects correctly can speed up your I/O, protect your files and simplify your code.
In part 2, Jason will map the business-readable tests we created last time to test automation code.
- By Jason Roberts
You've got data on your server that you need in your page. Here are all the solutions you require, including one that will make your application more scalable.
SpecFlow 2 makes sure developers deliver what businesses say they want. In this first of a two-part series, Jason looks at how to automate the process of communication through business-readable tests.
- By Jason Roberts
Best practices and principles aren't rules. They're guides to the judgement of the programmer. Sometimes we forget that.
When you need to share a list of specific information between asynchronous processes, you probably need the ConcurrentDictionary. Except, of course, when you don't.
When it's important to know what path your application took when processing data, a log of that path can be helpful. And, when you need to make a decision in your code based on an earlier decision, that internal path can make your code both simpler and easier to understand.
If you're creating an asynchronous application (and you should be) you'll be glad to know that .NET offers ways to share data that don't require you to lock up your application.
The basic functionality of the BlockingCollection makes creating asynchronous applications easy to do. But you need to use some of the BlockingCollection's other tools to create applications that handle typical real-world problems.