In the last article we replaced the standard WCF service client with an improved version. But beyond solving an issue with cleaning up the client we haven’t really improved the calling code any. In this article we are going to look at one approach for making the calling code cleaner. The less code that is needed to call something the cleaner it tends to make code. We will present one approach for making WCF calls one-liners. This is not always the best solution so we will talk about the disadvantages as well.
In the last article we made a case for why the standard WCF client generated by a service reference is not a great idea. Among the issues listed were testability and proper cleanup. To fix these issues we will need to ultimately replace service references altogether but this is time consuming for large code bases. When we started down this path at my company we did it using an iterative approach. While the intermediate stages may appear to be (and, in fact, may be) a step back we are ultimately working toward a solution that I believe is far better.
WCF is a great way to implement service-based APIs but the standard approach to consuming a service lacks a lot to be desired. In this series of articles I will discuss the approach that I’ve used in commercial applications to make consuming WCF services much cleaner and simpler. We will start with the standard approach and identify its flaws. From there we will work toward a solution that has minimal impact on consumers while providing maximal benefit. The solution itself is large but not overly complex. More importantly, once finished, you never need to worry about it again.
UPDATE: A bug was recently found when determining the difference between 2 dates across a year boundary. A corrected version has been uploaded to the site.
In .NET the DateTime type represents both a date and a time. .NET doesn’t really have a pure date type. Ironically it does have a pure time type in the form of TimeSpan. In general this isn’t an issue but when you really just need a date (i.e. the end of a grading period) then you have to be aware of the time. For example when comparing 2 date/time values the time is included in the comparison even if it does not matter. To eliminate time from the comparison you would need to set both to the same value (i.e. 00:00:00). Another example is conversion to a string. A date/time value will include the time so you have to use a format string to eliminate it. Yet another issue is that creating specific dates using
DateTime isn’t exactly readable (i.e. July 4th, 2000 is
new DateTime(2000, 4, 4)).
I was incredibly excited when conventions were finally made public in EF6. A convention allows you to set up a policy that a model will follow. For example EF comes with a convention that tables are plural by entities are singular. EF has supported conventions for a while but the necessary public interface was not exposed until EF6. In this post I’m going to walk through creating a simple convention.
.NET uses Type everywhere to represent type information.Not surprisingly Type is language-agnostic. In many cases it is useful to get the friendly (aka language-specific) name for a Type object. .NET does not provide this easily. There are several different approaches but none of them work really well if you want the name that would have been used in your favorite language. This post will discuss some of the options available and then provide a more general solution to the problem that doesn’t actually require much effort.
Auditing is generally important in most databases because it is important to know who changed data and when. How auditing data is stored depends upon the system requirements but in general the date/time and user who made a change is important. SQL Server already provides the infrastructure to identify the who and what. Setting up EF to provide this information is straightforward once you know how EF works. In this post I’ll illustrate a simple approach we’ve been using in web applications for over a year with no issues and very little effort.
In a recent series of articles I discussed how to create an environmental tranform template that could be run on each build. I also posted a series of articles on how to generate a template to generate a strongly typed class to back appsettings in a configuration file. Alas shortly thereafter VS2013 Preview was released and changes to VS have broken the code. This post will discuss the minor changes that need to be made to get everything to work.
Note: This is strictly my opinion and in no way should be conveyed as the opinion of anyone else.
Now that the Win 8.1 Preview is out I can give my personal opinion on it. First we should discuss some of the new features and then whether it is a mandatory upgrade or not. Note that I’m ignoring all the new features around corporate environments and Windows Store apps.
In the previous article we updated the build process to support environmental config transforms in projects and to have the transforms run on any build. In this article we are going to package up the implementation to make it very easy to add to any project. There are a couple of things we want to wrap up.
- Place the .targets file into a shared location
- Add an import into the current project to the .targets file
- Add environmental config transforms into the project
- Remove the default config transforms generated by Visual Studio