3 ms·

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

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.
Daniel_Newby 16y ago
> I find it hard to imagine another way to get code that is as easy to test and to mock. Any suggestion? If you need a special data store for testing, just point the ORM at a test database. You don't need a half-assed database simulator when you can have as many real databases as you need.
- mononcqc 16y ago
  That doesn't let you test ORM queries alone or controller code alone, though. They get bundled together and the testing is necessarily done on a higher level. I guess this can be acceptable in most situations.
  - cageface 16y ago
    I actually prefer this most of the time. Bugs tend to crop up between stack layers so testing as much of the stack as possible at once is more effective, IMO.

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.

Daniel_Newby 16y ago

> I find it hard to imagine another way to get code that is as easy to test and to mock. Any suggestion? If you need a special data store for testing, just point the ORM at a test database. You don't need a half-assed database simulator when you can have as many real databases as you need.

mononcqc 16y ago
That doesn't let you test ORM queries alone or controller code alone, though. They get bundled together and the testing is necessarily done on a higher level. I guess this can be acceptable in most situations.
- cageface 16y ago
  I actually prefer this most of the time. Bugs tend to crop up between stack layers so testing as much of the stack as possible at once is more effective, IMO.