3 ms·
The principle is that you should be using the underlying API if something is already solved on a lower level, and not replicate the functionality on a higher le
by Arwill 4y ago
The principle is that you should be using the underlying API if something is already solved on a lower level, and not replicate the functionality on a higher level, because it will perform poorly. There was a reason why the lower level API exists in the first place.
This applies to graphics programming very well, its not a question that you wouldn't be making your own pixel rasterizer instead of using DX, OpenGL or Vulkan, for example.
The big recognition is that when doing business apps, SQL database functionality is the underlying API, and you should prefer using that.
- nonethewiser 4y ago> The principle is that you should be using the underlying API if something is already solved on a lower level I think you're making a great point but I want to consider what this suggests about ORM's. Using an ORM means you're not directly using the underlying API. In theory an ORM should be a very small "distance" from the underlying API. When that's the case, they are a no-brainer. But no ORM has 100% feature parity and for more complex queries this distance from the underlying API can grow considerably. And if you insist on ONLY using the ORM API then you're going to find yourself doing some pretty dumb shit in the application layer. Personally I think ORM's are great, but there is this common problem of over-insisting on their API and treating raw SQL as the devil.