I'm working on a new workshop that will guide students through an array of different data access approaches for OO languages (.NET/C# specifically). I like to start such topics off with principles that apply to the space. Here's what I have so far - am I missing anything obvious?
These are "data access principles" which when I searched I didn't find any handy lists. I'll probably write up a blog post on the topic soon.
Acquire late; release early.
This applies to any shared, external resource, such as a database connection. It's a low level principle that most modern developers don't even think about, but I think it's still worth mentioning.
This applies to any shared, external resource, such as a database connection. It's a low level principle that most modern developers don't even think about, but I think it's still worth mentioning.
Prefer chunky to chatty interfaces.
This assumes data access is not local to the application, which is typical for most web apps. A native app with an integrated data store might not need to follow this.
This assumes data access is not local to the application, which is typical for most web apps. A native app with an integrated data store might not need to follow this.
Fetch only what you need.
Avoid getting more data than you need. This applies both to number of rows and number of columns (if thinking in tabular terms). Overfetching leads to performance issues at every level of the stack.
Avoid getting more data than you need. This applies both to number of rows and number of columns (if thinking in tabular terms). Overfetching leads to performance issues at every level of the stack.
Cache frequently-used, rarely-changing data.
Such data is frequently referred to as "read-mostly". Basically, avoid constantly asking your database for the exact same data, especially if you're doing it multiple times per second.
Such data is frequently referred to as "read-mostly". Basically, avoid constantly asking your database for the exact same data, especially if you're doing it multiple times per second.
Don't Repeat Yourself.
The DRY principle applies to data access code. Most of the patterns and abstractions we use for data access are meant to reduce the amount of repetitive plumbing code we write, so we can focus on higher level concerns (and make fewer mistakes).
The DRY principle applies to data access code. Most of the patterns and abstractions we use for data access are meant to reduce the amount of repetitive plumbing code we write, so we can focus on higher level concerns (and make fewer mistakes).
Command Query Responsibility Segregation.
This often only becomes important with the need to scale or other requirements, but considering it from the start can make such changes easier.
This often only becomes important with the need to scale or other requirements, but considering it from the start can make such changes easier.
Those are the main principles. These 4 SOLID principles also apply:
Single Responsibility
Open/Closed
Interface Segregation
Dependency Inversion
I don't have a great example of Liskov Substitution mattering to much in the context of data access or I'd just say all of SOLID...
Single Responsibility
Open/Closed
Interface Segregation
Dependency Inversion
I don't have a great example of Liskov Substitution mattering to much in the context of data access or I'd just say all of SOLID...
This is for an NDC workshop next week, if you're curious. You can sign up here still:
ndcmelbourne.com/agenda?day=29-…
ndcmelbourne.com/agenda?day=29-…
Now my request to you: In the words of Thomas Jefferson,
🎶"So what'd I miss?"🎵
What fundamental principle(s) of data access would you include that I haven't covered in the above thread?
#programming #dotnet #csharp
🎶"So what'd I miss?"🎵
What fundamental principle(s) of data access would you include that I haven't covered in the above thread?
#programming #dotnet #csharp
*too much*
I published my list in article form here:
ardalis.com/data-access-pr…
ardalis.com/data-access-pr…
