Data Access with Dapper.CX - adamfoneil/CloudObjects GitHub Wiki

This is how I use my CRUD library Dapper.CX in this project:

  • In Startup, I add the DapperCX service to the service collection. I pass the connection string along with a delegate that tells DapperCX how to treat identity values created by INSERT statements. I'm using long Id values in this project, hence the Convert.ToInt64 method. Note that DapperCX can have a TUser type argument. In this project it's not needed, so I'm using the simpler form without TUser.
services.AddDapperCX(connectionString, (id) => Convert.ToInt64(id));

  • I have a CommonController that accepts a DapperCX<long> instance. Here's a reference on the DapperCX<T> service.

  • You can see Dapper.CX in action here: inserting, merging, getting, updating, deleting. General purpose SQL queries are done with my Dapper.QX library, example here.

  • Model classes come from the Models project. This is what I build my physical database from using my homegrown app Model Sync,

  • Backend-specific trigger and validation behavior is done by splitting my model classes into partial classes, found here inside the App project. I've come to have mixed feelings about this partial class approach because it leads to some testing complications.

  • For local development, you can see how a local database instance is created here.

Note that having a convention-driven approach to the data access layer that factors out all code redundancy is really important to me. Conventions appear in two places:

  • In the Model project. This defines my BaseTable model which tells every table to have a long Id column. It also defines my AuditedTable model, which standardizes how I capture timestamps and row Ids for modified rows.
  • And in the App project, the other half of my AuditedTable partial class handles common trigger and timestamp actions.
⚠️ **GitHub.com Fallback** ⚠️