| This is the kind of anti-pattern that can work on toy or small projects but doesn't scale well to larger projects or groups. > 1. Very difficult for devs to expose SQL injection vulnerabilities because you need to use parameters. You should use parameters either way. > 2. Having all available filtering dimensions on a query makes it very clear what the type of filtering is for that particular query. Code is easier to document well than a SQL query > 3. Easy debugging where you can just throw your query into an SQL client and play around with the parameters. Query builders will give you a query you can do the same thing with. > 4. Very clear what the total query footprint of you application is (e.g. files all neatly listed in a dir). This seems like a design/organization choice that is separate from whether those files are query or code. > 5. Super readable and editable. Doesn't scale as a project grows, you end up with massive unwieldy queries or a bunch of duplicated code across a bunch of files. > 6. Code for running the SQL is pretty much: here is my query, here are my params, execute. It is pretty much the same with a query builder, in either case the 'execute' is calling a library where all the actual stuff happens. If you know your project is gonna stay small with simple queries and your scope won't creep, raw SQL files might the right choice, but they will create technical debt as the project grows. It's worth the time in the long run to get comfortable with a query builder. |