YARPI: Yet Another Repository Pattern Implementation

Following-up on this post, I wanted to be able to put a copy of that Excel workbook on a USB key and take it home to keep working on the code a bit (there's more than just one or two tables to maintain, so I'll have about a dozen forms when I'm done)... but to be able to test every functionality of my CRUD app without actually hitting the database, I had to get the abstraction level much higher than the typical vba "macro". Guess what abstraction first came to my mind.

(comments added for reviewers' convenience, they're not in the actual code)

IRepository class module

Option Explicit

Public Function GetById(ByVal id As Long) As SqlResultRow
    'because, all my tables have an Id primary key.
End Function

Public Function GetAll() As SqlResult
End Function

Public Function Count() As Long
End Function

Public Sub Add(ByVal value As SqlResultRow)
End Sub

Public Sub Remove(ByVal id As Long)
End Sub

Public Sub Update(ByVal id As Long, ByVal value As SqlResultRow)
End Sub

Public Function NewItem(ByVal model As SqlResult, ByVal values As Dictionary) As SqlResultRow
    'creates a new item, out of a Scripting.Dictionary containing field names & values.
    'model: contains the field names.
    'values: field names as key, field values for values.
End Function

Before going directly into an implementation of that interface, you need to know a little bit about the classes involved here, if you haven't seen this post (Materializing any ADODB Query) and this post (Creating ADODB Parameters on the fly), they're the foundation that led to this.
About SqlResult & SqlResultRow

All QuickXxxxx methods in the SqlCommand class iterate and consume the ADODB recordset, and take care of opening/closing the connections and the recordset. Because the results have already been iterated when the method returns, the data ends up iterated twice - once in SqlCommand (iterating the recordset), and once in the client code (iterating the DTO's). It's a tradeoff for abstractio

I think this is pretty much done. You have great naming. No glaring bugs as far as I can tell. It's clear and concise. Very OOP, which is impressive given the language. Even the high level design seems pretty darn tight. (I know very little about dependency injection though. I could have missed something that would be obvious to someone else.)

I just can't find anything to pick apart. Well done. Thank you for helping me make the case that VBA is a legitimate programming language in the right hands.

StackExchange Code Review Q#57889, answer score: 8