4 ms·

> A good ORM user is thinking in SQL but writing in C# (or whatever your business layer is in). That doesn't sound like metaprogramming; it sounds like insanit

> A good ORM user is thinking in SQL but writing in C# (or whatever your business layer is in). That doesn't sound like metaprogramming; it sounds like insanity brought about by bureaucratic limitations on language choice.

fifilura 4y ago
To be fair, there is one important thing the ORM brings though. Sanatizing inputs.
- zanecodes 4y ago
  Don't sanitize your inputs; parameterize your queries instead.
  - Tostino 4y ago
    I see those as two different solutions to two different, but slightly overlapping problems.
    - pessimizer 4y ago
      Going to keep those problems a secret?
    - Lvl999Noob 4y ago
      Imo, the problems are the same but the conditions are different. If the query is used many times, parameterize it. If the input is used many times, sanitize it. If both are used many times, parameterize.
  - robocat 4y ago
    Parameterising works for individual fields in a statement. However for complex queries (the reason for the meta-programmimg comment) you can’t always parameterise the additional subqueries/tables/fields. You can use stored procedures, but that just shifts the necessary code from one language to SQL, and the SQL doesn’t have a robust library you can just use.
goto11 4y ago
It should be "thinking in relational algebra but writing in C#". Arguable Linq with C# represent relational algebra better than SQL.
- fijiaarone 4y ago
  But not more efficiently. Working with small datasets in memory can be fast, but larger datasets consumes more memory and cpu. The purpose of a database is to efficiently store and retrieve data from disk — and limiting it to only the data you need. Most database interactions are also over a network, which is always slower than (and in addition to) disk retrieval. This should not be done except when you cannot fit the data on disk (or work with it in memory) on the same system. Services should not be separated except for the same reasons (exceeding computation or memory) for the same reasons (network, disk latency). We used to perform billions of complex computations in seconds reading from slow disks and slow systems with much smaller memory footprints on single systems with single cpus. This article is a parable for the consequences of not understanding that. The Google and Amazon and Netflix etc white papers are about organizations that build solutions for applications that cannot fit on disk or in memory or be handled by the computation of a single system — and do not apply to 99% of application architectures that use them, including those developed by Google, Amazon, etc.
feoren 4y ago
Consider a function that takes an IQueryable<T> (for any T) and connects it with your change tracking logic to return an IQueryable<Tracked<T>>, or connects it with your comments system to return an IQueryable<Commented<T>>. I can take a query of (nearly) arbitrary complexity represented by an IQueryable<ComplexModel> and turn it into an IQueryable<Tracked<Commented<ComplexModel>>> in one line, while still keeping the result as a single SQL statement. If you hate that type, note that it's almost never explicitly written out like that (thank you, 'var' keyword). On the other hand, your databases have a "Comments" field in every table; a "LastModifiedBy" in every table. Your database tables grossly violate the single responsibility principle: every single cross-cutting concern is represented in every single one of your "primary" tables. (Level up: every concern is a cross-cutting concern.) Your databases have association tables between X and Y for every primary data type X and every cross-cutting concern Y, leading to a combinatorial explosion of redundant tables. Your SQL queries/views/procedures/triggers are repetitive and full of boilerplate. If your client told you they needed you to change how change tracking is done in your system, you'd have to touch nearly every single SQL module in your entire system. For me, I need to change the implementation of IChangeTrackingSystem, and that's literally all. All of my other queries don't have to know about the change, because they're simply composed together with whichever IChangeTrackingSystem is in place. Show me how to do that in T-SQL and I'll reconsider my position. Now that I've tasted this fruit, the old way of doing things sounds like insanity to me. You're being needlessly zealous and close-minded here. Edit: And another thing! (Shakes fist) Much of the beauty of modern programming languages is their adaptability to whichever domain you're working in. We no longer need domain-specific languages for every different task, because we can embed those languages inside our parent language; then we don't have to reinvent static typing, write a new IDE, and learn decades of programming language design before we can start on our actual business logic. So, yes: When writing data access logic, you should be thinking in SQL (or generic relational logic) but writing in C#. When writing a game renderer, you should be thinking in linear algebra, but writing in C#. When writing a payroll processing system, you should be thinking in payroll, but writing in C#. When writing a chemical engineering toolbox, you should be thinking in molecules and reactions and units, but writing in C#. This way, anyone who knows C# is already halfway (yes, only half) toward being able to maintain your system. If you insist on using a DSL for every single one of these tasks, 80% of your time will be spent on context switching and trying to get them to talk to each other correctly and correcting issues in the DSL itself. Of course I do often write raw SQL as views and scripts, and of course I write TypeScript and HTML and CSS/SASS when working on a front-end (although I usually "think in HTML and write in TypeScript", not surprisingly). But that's mostly for development and maintenance; not for core business logic or library development.
robocat 4y ago
Let us assume you accept that writing SQL is better than writing the equivalent machine code. The “meta-programming” is stating there is a “language” representing their problems that is better than SQL. If we call that better framework(language) Blub[1] then that is probably a good metaphor, rather than causing people to get triggered by the generic ORM tag. [1] https://www.benkuhn.net/blub/ https://www.benkuhn.net/blub/

fifilura 4y ago

To be fair, there is one important thing the ORM brings though. Sanatizing inputs.

zanecodes 4y ago
Don't sanitize your inputs; parameterize your queries instead.
- Tostino 4y ago
  I see those as two different solutions to two different, but slightly overlapping problems.
  - pessimizer 4y ago
    Going to keep those problems a secret?
  - Lvl999Noob 4y ago
    Imo, the problems are the same but the conditions are different. If the query is used many times, parameterize it. If the input is used many times, sanitize it. If both are used many times, parameterize.
- robocat 4y ago
  Parameterising works for individual fields in a statement. However for complex queries (the reason for the meta-programmimg comment) you can’t always parameterise the additional subqueries/tables/fields. You can use stored procedures, but that just shifts the necessary code from one language to SQL, and the SQL doesn’t have a robust library you can just use.

goto11 4y ago

It should be "thinking in relational algebra but writing in C#". Arguable Linq with C# represent relational algebra better than SQL.

fijiaarone 4y ago
But not more efficiently. Working with small datasets in memory can be fast, but larger datasets consumes more memory and cpu. The purpose of a database is to efficiently store and retrieve data from disk — and limiting it to only the data you need. Most database interactions are also over a network, which is always slower than (and in addition to) disk retrieval. This should not be done except when you cannot fit the data on disk (or work with it in memory) on the same system. Services should not be separated except for the same reasons (exceeding computation or memory) for the same reasons (network, disk latency). We used to perform billions of complex computations in seconds reading from slow disks and slow systems with much smaller memory footprints on single systems with single cpus. This article is a parable for the consequences of not understanding that. The Google and Amazon and Netflix etc white papers are about organizations that build solutions for applications that cannot fit on disk or in memory or be handled by the computation of a single system — and do not apply to 99% of application architectures that use them, including those developed by Google, Amazon, etc.

feoren 4y ago

Consider a function that takes an IQueryable<T> (for any T) and connects it with your change tracking logic to return an IQueryable<Tracked<T>>, or connects it with your comments system to return an IQueryable<Commented<T>>. I can take a query of (nearly) arbitrary complexity represented by an IQueryable<ComplexModel> and turn it into an IQueryable<Tracked<Commented<ComplexModel>>> in one line, while still keeping the result as a single SQL statement. If you hate that type, note that it's almost never explicitly written out like that (thank you, 'var' keyword). On the other hand, your databases have a "Comments" field in every table; a "LastModifiedBy" in every table. Your database tables grossly violate the single responsibility principle: every single cross-cutting concern is represented in every single one of your "primary" tables. (Level up: every concern is a cross-cutting concern.) Your databases have association tables between X and Y for every primary data type X and every cross-cutting concern Y, leading to a combinatorial explosion of redundant tables. Your SQL queries/views/procedures/triggers are repetitive and full of boilerplate. If your client told you they needed you to change how change tracking is done in your system, you'd have to touch nearly every single SQL module in your entire system. For me, I need to change the implementation of IChangeTrackingSystem, and that's literally all. All of my other queries don't have to know about the change, because they're simply composed together with whichever IChangeTrackingSystem is in place. Show me how to do that in T-SQL and I'll reconsider my position. Now that I've tasted this fruit, the old way of doing things sounds like insanity to me. You're being needlessly zealous and close-minded here. Edit: And another thing! (Shakes fist) Much of the beauty of modern programming languages is their adaptability to whichever domain you're working in. We no longer need domain-specific languages for every different task, because we can embed those languages inside our parent language; then we don't have to reinvent static typing, write a new IDE, and learn decades of programming language design before we can start on our actual business logic. So, yes: When writing data access logic, you should be thinking in SQL (or generic relational logic) but writing in C#. When writing a game renderer, you should be thinking in linear algebra, but writing in C#. When writing a payroll processing system, you should be thinking in payroll, but writing in C#. When writing a chemical engineering toolbox, you should be thinking in molecules and reactions and units, but writing in C#. This way, anyone who knows C# is already halfway (yes, only half) toward being able to maintain your system. If you insist on using a DSL for every single one of these tasks, 80% of your time will be spent on context switching and trying to get them to talk to each other correctly and correcting issues in the DSL itself. Of course I do often write raw SQL as views and scripts, and of course I write TypeScript and HTML and CSS/SASS when working on a front-end (although I usually "think in HTML and write in TypeScript", not surprisingly). But that's mostly for development and maintenance; not for core business logic or library development.

robocat 4y ago

Let us assume you accept that writing SQL is better than writing the equivalent machine code. The “meta-programming” is stating there is a “language” representing their problems that is better than SQL. If we call that better framework(language) Blub[1] then that is probably a good metaphor, rather than causing people to get triggered by the generic ORM tag. [1] https://www.benkuhn.net/blub/ https://www.benkuhn.net/blub/