5 ms·

I think we call these Named Scopes: http://api.rubyonrails.org/classes/ActiveRecord/NamedScope/ClassMethods.html http://api.rubyonrails.org/classes/ActiveRecord

I think we call these Named Scopes: http://api.rubyonrails.org/classes/ActiveRecord/NamedScope/ClassMethods.html http://api.rubyonrails.org/classes/ActiveRecord/NamedScope/C... Maybe it's this in Django: http://docs.djangoproject.com/en/dev/topics/db/managers/#modifying-initial-manager-querysets http://docs.djangoproject.com/en/dev/topics/db/managers/#mod... The overall purist argument, that the controller should have no knowledge of the database seems ridiculous. If one removes or adds a field to the model, one would expect there to be cascading changes across the whole system. If you generate most of your SQL with an ORM, you can switch database with minimal fuss. Although, how often do you do that anyway? ORM provides a lot of benefit in reducing the amount of code you have to write for many operations.

cageface 16y ago
Beginning programmers make the mistake of abstracting too little. Intermediate programmers make the mistake of abstracting too much. Experienced programmers know when abstractions add value and when they just add another layer of extra complexity. Generally speaking, designing your code up front to answer vague & ill-defined portability concerns you may encounter down the road means you're abstracting too much & too early.
- acangiano 16y ago
  Extremely accurate statement in my experience.
- mononcqc 16y ago
  Can't help but feel this is directed at the post. While I can definitely agree doing it for every single ORM call for maintenance purposes is sometimes overkill (some calls just are easy to refactor, or following a rule similar to "3-strikes you're out" keeps it sane), I find it hard to imagine another way to get code that is as easy to test and to mock. Any suggestion? Then I think Groxx hit the nail on the head with his comment (http://news.ycombinator.com/item?id=1636322 http://news.ycombinator.com/item?id=1636322). The advice is mostly valid for large-scale projects, things you expect to stay forever, which is what I'm maintaining at the moment; Not for experimental or short-lived code (or whatever is logical on that spectrum).
  - cageface 16y ago
    In modern web stacks you're already separated your view from your controller from your models, and you've abstracted most or all of your database code into an ORM. That's a lot of framework to punch through when your abstractions start to leak already. At some level your controller has to know something about what objects exist in your database and what fields they contain. I've also found it's extremely hard to predict ahead of time what projects will turn out to be long lived and large scale so I try to build the simplest thing possible first and then take advantage of the flexibility of modern stacks to iterate and refactor from there. Things like named scopes in rails should be more than enough to keep your controllers from getting too tightly intertwined with your models.
    - mononcqc 16y ago
      I can see what you mean by the controller needing to know something about the objects it will obtain. It makes sense, although I guess we might disagree on how much info we want to let go through. I think predicting the length and scale of projects likely depends on who you work for and what products they want. I might be biased because I've spent most of my professional life working for a large-ish business where products in general end up being reused a lot by other internal products and all have an active life of at least 3 to 5 years, during which different developers will 'own' them. In this case, you can understand how planning ahead might be necessary. I'm currently supporting an application that's 14 years old and small leaks like that end up hurting a whole lot. Then I guess I'm not as strict for home projects where I'll be the sole owner and developer, but that's the opposite end of the spectrum.
      - cageface 16y ago
        I might be biased because I've spent most of my professional life working for a large-ish business where products in general end up being reused a lot by other internal products and all have an active life of at least 3 to 5 years The interesting and frustrating thing about building software is that the answer to most questions is "it depends". What you're describing may be appropriate in your case. In the case of most of the projects I've been involved with adding any significant extra abstraction on top of reasonable use of an ORM would be overkill in most places.

cageface 16y ago

Beginning programmers make the mistake of abstracting too little. Intermediate programmers make the mistake of abstracting too much. Experienced programmers know when abstractions add value and when they just add another layer of extra complexity. Generally speaking, designing your code up front to answer vague & ill-defined portability concerns you may encounter down the road means you're abstracting too much & too early.

acangiano 16y ago
Extremely accurate statement in my experience.
mononcqc 16y ago
Can't help but feel this is directed at the post. While I can definitely agree doing it for every single ORM call for maintenance purposes is sometimes overkill (some calls just are easy to refactor, or following a rule similar to "3-strikes you're out" keeps it sane), I find it hard to imagine another way to get code that is as easy to test and to mock. Any suggestion? Then I think Groxx hit the nail on the head with his comment (http://news.ycombinator.com/item?id=1636322 http://news.ycombinator.com/item?id=1636322). The advice is mostly valid for large-scale projects, things you expect to stay forever, which is what I'm maintaining at the moment; Not for experimental or short-lived code (or whatever is logical on that spectrum).
- cageface 16y ago
  In modern web stacks you're already separated your view from your controller from your models, and you've abstracted most or all of your database code into an ORM. That's a lot of framework to punch through when your abstractions start to leak already. At some level your controller has to know something about what objects exist in your database and what fields they contain. I've also found it's extremely hard to predict ahead of time what projects will turn out to be long lived and large scale so I try to build the simplest thing possible first and then take advantage of the flexibility of modern stacks to iterate and refactor from there. Things like named scopes in rails should be more than enough to keep your controllers from getting too tightly intertwined with your models.
  - mononcqc 16y ago
    I can see what you mean by the controller needing to know something about the objects it will obtain. It makes sense, although I guess we might disagree on how much info we want to let go through. I think predicting the length and scale of projects likely depends on who you work for and what products they want. I might be biased because I've spent most of my professional life working for a large-ish business where products in general end up being reused a lot by other internal products and all have an active life of at least 3 to 5 years, during which different developers will 'own' them. In this case, you can understand how planning ahead might be necessary. I'm currently supporting an application that's 14 years old and small leaks like that end up hurting a whole lot. Then I guess I'm not as strict for home projects where I'll be the sole owner and developer, but that's the opposite end of the spectrum.
    - cageface 16y ago
      I might be biased because I've spent most of my professional life working for a large-ish business where products in general end up being reused a lot by other internal products and all have an active life of at least 3 to 5 years The interesting and frustrating thing about building software is that the answer to most questions is "it depends". What you're describing may be appropriate in your case. In the case of most of the projects I've been involved with adding any significant extra abstraction on top of reasonable use of an ORM would be overkill in most places.