This is a continuation of the series on simplifying data access using ADO.NET. We have a little cleanup to do around parameters before finishing up the series.
One of the cool new features coming in C# v6 is the nameof operator. This handy little operator solves a common code smell, string literals for programmatic items. Let’s take a simple example.
This is a continuation of a series on simplifying the use of ADO.NET. In the last article we added the ability to cleanly separate query definition from the underlying data provider. But we left out parameters which are generally critical (and specific) to ADO.NET providers. In this article we will add support for parameters and add a fluent interface to make it easy to use.
One of the changes coming with VS 2015 is how NuGet packages are managed. In VS2013 you got something like this when managing packages for a solution.
UPDATE:Visual Studio 2015 also has a Community Edition.
This is awesome news from Microsoft. They have finally released a new edition for VS2013. Now before you grumble about yet another edition let me clarify exactly what this means – Express is dead.
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.