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.
Recently I was writing some code for one of my personal projects and I ran across this error in the first Entity Framework call I made – System.ArgumentException ‘DbLimitExpression’ requires a collection argument. Haven’t seen that one before. For anyone running into this issue here’s how I figured it out.
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.
Entity Framework 6 Conventions
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.
Entity Framework and User Context
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.