In this article I have collated a few training links about Windows Communication Foundation. I will keep adding to this page as I find other useful free resources. If you have any videos or articles that you feel would be useful here then please let me know in the comments and I will add them to the post. I would like it to be an archive of good material.
This training page contains tutorials for WCF. This page also contains links to useful sites with more information about WCF Bindings including the basicHttpBonding, wsHttpBinding, netTcpBinding, Names Pipes and the netMSMQBinding.
There is also a section on hosting WCF services in IIS, as self host windows services and also using IIS and the Windows Activation Services (WAS). There is also a section about performance tuning WCF services.
In this section you will find links to some basic WCF tutorial to help you get started in services development.
In this article I have collated a few training links about ASP.NET MVC. I will keep adding to this page as I find other useful free resources. If you have any videos or articles that you feel would be useful here then please let me know in the comments and I will add them to the post. I would like it to be an archive of good material.
In this article I have collated a few training links about .NET 4 and 4.5. I will keep adding to this page as I find other useful free resources. If you have any videos or articles that you feel would be useful here then please let me know in the comments and I will add them to the post. I would like it to be an archive of good material.
A little while ago I wrote an article about training for software developers. This article focused mainly on developers increasing their technical knowledge. In this article I want to expand on that and talk about a developer’s skills matrix that we use in my department. The skills matrix discussed here was originally put in place by our old development manager, Duncan, with input initially by me and the other leads at the time. Once we had the base matrix in place we gave the developers an opportunity to contribute to it.
In our company we have 3 levels of developer under the team leaders. They are Entry Level Developers, Developers and Senior Developers. The skills matrix is split into 3 sections, Knowledge, Skill and Behavior.
Knowledge is the information we expect developers at each level to know as a minimum.
Skills are what we expect a developer to be able to do, i.e. the doing.
Behavior represents the habits of a developer.
Let’s use an example of source control. For knowledge we would expect someone to have a good understanding of source control concepts. Why do we use source control? What types of source control system are out there? What is branching and merging etc? For Skills we expect someone to be able to use their tools. In our case this is Microsoft’s Team Foundation Server. Can they check in code? Can they merge conflicts? Can they go back to previous revisions? Can they create branches? Behavior is more about their day to day usage. Do they regularly check in code as a habit? Do they keep an eye on builds? Do they fix broken builds? Are they branching on release?
In this article I want to talk about an architectural pattern called Command Query Responsibility Segregation (CQRS). I will use an example to illustrate this pattern based on a recent problem we had at the company I work for and how we solved that problem. The system in question is an automated payment processor and runs on a schedule through the night and collects payments from our customers. The original CQRS pattern was written about by Martin Fowler over on his blog.
The concepts behind CQRS are very simple, but they give you some powerful advantages. What CQRS essentially does is get you to use a different model to update information (COMMAND) than the mode you use to read information (QUERY). If you think of a typical layered application you may have a client, a user interface or a background process that communicates with a business logic layer that may be comprised of a static set of libraries, Web Services or REST based services.
This business logic layer acts as a model into your domain that lets you perform operations against that model. These operations generally allow you to create, retrieve, update, or delete data associated with the model. For most scenarios this age old way of working is fine and that is certainly true nowadays. This way of working can cause you problems for systems that need to have high performance and be more scalable.
To illustrate this pattern I will discuss a payment system developed by 2 engineers on my team, Graham Johnson and Hugh Hulme. For the purposes of this article we will call it the Automated Payment System (APS). The actual system itself had a different name but APS will do for the purpose of this article. The system would run through the night and collect payments that where due from our customers. The initial system was completely synchronous and would execute in the following steps: