Weird Cultural Practice
SQL in string literals is just the weirdest cultural practice. What other terms can describe it? Is there any equivalent in all computing? When HTML appeared, we were "brute force" generating HTML for, what, five minutes before we came up with "code in markup" strategies? How do you explain that, after 30 years of using SQL, there seems to be zero awareness of the cost, the craziness, of burying SQL in string literals, using host language conditionals and control structures to spit out SQL when SQL has conditionals and control structures? Dapper, Massive and PetaPoco, modern tools that have put SQL back in the toolset, do nothing to challenge this long-running oddity. One prominent developer told me he didn't see the problem, his SQL in string literals was covered by unit tests! This is a language, that can be validated and integration-tested, but not if it's buried in double quotes, it's final form only discoverable by running the program.I didn't invent putting sql in it's own file. But by automating a couple of steps, I made the right way the easiest way, and removed some possibilities that developers are much better off without.
Leverage powerful tools
The SQL window in Visual Studio is just sitting there waiting to be useful. The editor window connects to your database, for context sensitive code completion. SQL Server has a marvelous stored proc, sp_describe_undeclared_parameters. So why not write your SQL in a real environment, and you never have to remember a column name, or a db type, or its C# equivalent? When the code wrapper is generated, the type information flows straight out of the database and into your app.
The long shadow of ORM's and n-tier
Even when folk go back to SQL for data access, the grip of ORMs and n-tier on the imagination is frightening. Folk are trying to use Dapper to write a DAL for every conceivable access before they tackle their domain layer. If queries can be easy to write and continually tested, we should write more of them, and bring back just what we need, just when we need it.
If you're using an RDBMS, then data reliably stored in a properly normalized schema is an outcome in itself, and a lot of your code should be preoccupied with getting this right. Your RDBMS is a lot more than an interchangeable persistence store for your objects. I can completely see the point in keeping your domain objects persistence-ignorant, but this is achieved just by putting persistence in separate classes (or in queries). Casting those classes to the opposite end of the application, in a separate project or layer, risks making artificially distant elements that are in fact tightly coupled, and is not going to help developers focus on what needs to happen in the DB.
I'm raving, I should stop!
