2 ms·

He could prefer SQL over ORM due to knowledge about object relational impedance mismatch, I often prefer SQL over ORM for lots of use cases. Maybe you could get

He could prefer SQL over ORM due to knowledge about object relational impedance mismatch, I often prefer SQL over ORM for lots of use cases. Maybe you could get him to use a query building API that handles escaping user input for him [like an ORM does], but still allows him to work in SQL which is preferable to ORM in many cases. For example if using PHP: https://github.com/jstayton/Miner https://github.com/jstayton/Miner

DrJokepu 11y ago
We're talking about .NET here and plain ADO.NET that comes with .NET will safely handle query parameters in raw SQL if used properly (DbCommand.AddParameter() etc). I suspect that the developer in question was simply concatenating the parameters with the command text string. He probably just never bothered to learn to use the runtime properly.
- moron4hire 11y ago
  That is the case. He creates a SqlCommand object and then concats the parameters he wants into the query string, rather than adding a parameter to the query, or creating an SP.
moron4hire 11y ago
Actually, we use an ORM that is just SQL. I learned a long time ago that I couldn't trust most of the developers I worked with to dispose their ADO.NET objects properly, and that given an inch to concatenate strings, they'll take a mile of SQL injection. So years ago I developed a system around const strings (defined in attributes tagged to methods, so you don't have any option, the string must be constant) and reflection. It's exactly, 100% the code you would write if you were writing ADO.NET code from scratch. It just doesn't give you the option of screwing it up. Stored Procedures get created automatically. You can prototype queries as text queries if you want, before flipping a switch to make them SPs. You don't have to worry about matching parameter names in the SP declaration correctly, because it's drawn from the method signature. The result sets map out to plain, ol' C# classes with 0 effort. And it all runs fast, because it doesn't do any sort of graph traversals to figure out type mappings. It just takes the first layer of reflection and runs the entire mapping against that. Not enough overhead to ever worry about. And he'd rather be super verbose and just write his own ADO.NET code, for no benefit and a whole lot of error.

DrJokepu 11y ago

We're talking about .NET here and plain ADO.NET that comes with .NET will safely handle query parameters in raw SQL if used properly (DbCommand.AddParameter() etc). I suspect that the developer in question was simply concatenating the parameters with the command text string. He probably just never bothered to learn to use the runtime properly.

moron4hire 11y ago
That is the case. He creates a SqlCommand object and then concats the parameters he wants into the query string, rather than adding a parameter to the query, or creating an SP.

moron4hire 11y ago

Actually, we use an ORM that is just SQL. I learned a long time ago that I couldn't trust most of the developers I worked with to dispose their ADO.NET objects properly, and that given an inch to concatenate strings, they'll take a mile of SQL injection. So years ago I developed a system around const strings (defined in attributes tagged to methods, so you don't have any option, the string must be constant) and reflection. It's exactly, 100% the code you would write if you were writing ADO.NET code from scratch. It just doesn't give you the option of screwing it up. Stored Procedures get created automatically. You can prototype queries as text queries if you want, before flipping a switch to make them SPs. You don't have to worry about matching parameter names in the SP declaration correctly, because it's drawn from the method signature. The result sets map out to plain, ol' C# classes with 0 effort. And it all runs fast, because it doesn't do any sort of graph traversals to figure out type mappings. It just takes the first layer of reflection and runs the entire mapping against that. Not enough overhead to ever worry about. And he'd rather be super verbose and just write his own ADO.NET code, for no benefit and a whole lot of error.