3 ms·
Even with Rails, i query by writing directly SQL code, instead of using ActiveRecord. Code is clean, no more layered abstraction for no purpose.
by revskill 7y ago
Even with Rails, i query by writing directly SQL code, instead of using ActiveRecord.
Code is clean, no more layered abstraction for no purpose.
- mrkeen 7y ago> no more layered abstraction for no purpose I agree with this. > i query by writing directly SQL code, instead of using ActiveRecord I haven't used ActiveRecord, but I'm sure I'd hate it and prefer direct SQL - if I were forced to choose between the two. So let me offer a third choice: an abstraction which serves an actual purpose, and is neither raw SQL nor ActiveRecord. Pretend your domain is about farming fruit. A naive design might be: FruitService -> FruitDatabase. The DI way is to change that to: FruitService -> Fruit <- FruitDatabase You effectively divide-and-conquer the problem, so that you can think about your fruity business rules in the Service, and think about fruity storage in the Database. When working in the Service, your might think about business thoughts like "We should throw away the 25% smallest green apples". When working in the Database, you might think "Do I like the amount of SQL normalisation? Did I miss any indexes? How do I model an apple at the SQL table level?" The purpose of this is to prevent you from thinking "Do I have an SQL column for colour?" when you're working on the business rules.
- revskill 7y agoIn your case, the logic of manipulating params to pass to SQL query doesn't change my PoV. No ORM layer when i query that "We should throw away the 25% smallest green apples". http request => controller => params manipulation => sql => database.