If you use .NET to talk to an Oracle database then you most likely are using ODP.NET. This is a .NET package provided by Oracle for communicating with their database. But using it has been historically difficult because of the dependencies. My company uses Oracle in a couple of applications and therefore uses ODP.NET but recently, as we are moving to .NET Core, we revisited this code and have been able to successfully upgrade to the newer ODP.NET Managed Driver.
Simplifying ADO.NET Data Access, Part 6
Time to finish up the series on simplifying data access using ADO.NET. We have simplified everything around ADO.NET except for actually retrieving the results. This is probably the most complicated part of ADO.NET given the need for cleaning up the reader, enumerating the results and reading the actual data. We can simplify all this logic down to a single line (plus any action to take for each row).
Simplifying ADO.NET Data Access, Part 5
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.
Simplifying ADO.NET Data Access, Part 4
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.
Simplifying ADO.NET Data Access, Part 3
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.
Simplifying ADO.NET Data Access, Part 2
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.
Simplifying ADO.NET Data Access, Part 1
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.