I did this once when designing an in-house programming language. It was a DSL for statisticians and it compiled down to C++. To get the users working quickly, I changed the parser so that anything between double ‘@’ pairs was emitted directly as C++. It was a good way to get people working as the language was being developed.
The repository offering an execSql method isn’t a punched-through abstraction. For example, where is that Transaction type coming from? The ORM? The ORM is also the DB abstraction layer?
I assume the repository is initialised with a connection to the database. That connection and the whole abstraction around the DB is what the author decided “punched-through” to…
My takeaway is that the author feels services should expose their dependencies.
Ugh… I know it’s not the point of the article but still hurts me to see sql that’s vulnerable to injections.
Ah you’re right. Fixed it.
I did this once when designing an in-house programming language. It was a DSL for statisticians and it compiled down to C++. To get the users working quickly, I changed the parser so that anything between double ‘@’ pairs was emitted directly as C++. It was a good way to get people working as the language was being developed.
The repository offering an
execSqlmethod isn’t a punched-through abstraction. For example, where is that Transaction type coming from? The ORM? The ORM is also the DB abstraction layer?I assume the repository is initialised with a connection to the database. That connection and the whole abstraction around the DB is what the author decided “punched-through” to…
My takeaway is that the author feels services should expose their dependencies.