In part 3 of this series on simplifying ADO.NET data access we will finally switch gears and start providing a cleaner approach. Under the hood we will continue to use ADO.NET but it will be wrapped in a provider-agnostic layer that doesn’t require any of the boilerplate code that we are used to seeing with ADO.NET.
Starting with Windows 8 (and continuing with Windows 8.1) I have noticed that changing your password is broken once the password is expired. I’m posting this so that others can be aware and not fall into the same pit that I often find myself.
Part 2 of a series on simplifying ADO.NET code.
In the previous article we talked about the basics of ADO.NET. There are times where ADO.NET is still the correct choice for data access. Unfortunately it was written back in the original days of .NET and hasn’t been updated with newer features like generics. In this article we will update the ADO.NET types to make them easier to use. This is a stepping stone to simplifying the overall data access process.
A while back we wanted to make some changes to our process template. The template was selected back when we switched to TFS 2010 and has been used every since. We’re using TFS 2013 now. The problem is that we had no idea which variant of template we were using. There are several flavors and versions of Agile, SCRUM and even CMMI. Searching online revealed that most people just recommend setting up a new team project but that was out of the question. We had years of history and work items that we didn’t want to migrate. So we opted to go through the tedious process of upgrading our template manually to the latest version before making our customizations. This is a summary of what we did in case anyone else needs to go down this road.
Even with the advent of ORMs, under the hood ADO.NET is still the core infrastructure used to access databases. There are many cases where using ADO.NET is still the easiest solution and oftentimes you find that you have to mix in some ADO.NET with your ORM calls. This is a testament to the solid design of ADO.NET. The biggest issue with ADO.NET is that it requires quite a bit of boilerplate code to retrieve data from the database. In this series of articles I’m going to demonstrate how I do data access when working with ADO.NET. The end result will be simple code to access any database in a (relatively) generic manner without the need for boilerplate code. Here’s a rough outline of where I’m going.
UPDATE: And then I saw this. Oh well, there went my idea.
Have you heard about Goat Simulator? How about Rock Simulator?With the advent of indie game devs we’re getting lots of great games but occasionally a few questionable ones show up. When I first heard about Goat Simulator I thought it was a joke. Later I found it available on Steam. A coworker bought it and said it was hilarious but it got repetitive after the first hour. That got me to thinking, maybe I can create my own simulation? So here you go: Cat Simulator.
In this series of articles I have been demonstrating a simple approach to making Windows services. In the previous article I discussed the different components generally involved in writing a service. I also provided the code for the service host and started working on the service instance. In this article I’m going to finish up the implementation of the service and demonstrate how all this comes together.
In the last article I provided an overview of Windows services and the issues involved in writing one compared to a normal program. In this article I will demonstrate how to write a simple service in a way that helps alleviate these issues. Before getting into the code for a service it is important to reiterate that a single process can host multiple services at the same time and each service can be started or stopped on its own. It is therefore useful to break up a service into its components so that each component does only what it is expected to do. When creating a service I find that there are 3 different components: service host, service instance(s), and service worker.
In Windows a service is a process whose lifetime is managed by the system rather than by a user. MSDN describes a service as a long running process and often times this is true. Services tend to start before a user logs in (or shortly thereafter) and run until the system shuts down. This is unlike traditional applications that start up after a user logs in and terminates when they log out. While a service looks a lot like a standard application they behave quite a bit differently. In this article I’ll discuss some of the issues around creating a service and ways to make it easier to write and debug one.
After a long delay I’m finally ready to finish up my series on creating a smarter WCF service client. Please refer to the previous articles for where we’re at.
- Identifying the issues with service references and the existing WCF client code
- Creating a smarter WCF service client
- Simplifying the calling of a WCF service
- Creating the skeleton client template
We’re now ready to generate the T4 template to back the client template.