3 ms·

I love how the comments are split along the lines of, "wait, some people don't do this?" and "this is a maintenance nightmare!" If you know, you know.

ChrisMarshallNY 2y ago
> this is a maintenance nightmare! Yeah, it's a pain to maintain, but it is damn secure.
- mattgreenrocks 2y ago
  Assuming reasonable factoring, maintenance is only a problem when trying to seriously cheat the layers, eg your controller wants to modify the template engine’s internals for a single request. Better to just be honest about it by punching a hole in the abstraction that is appropriately named and using that.
  - ChrisMarshallNY 2y ago
    No cheating! For example, I stop creating SQL, after the first layer above the DB access layer. Everything above that, is a function-based abstraction, so there's no SQL, in most of the stack. Some layers are meant to introduce "replacement points," so you could swap out the SQL for a NoSQL solution, if you want. Most layers have a fair bit of validation and permission-checking, etc. But making sure that I stick to the rules for each layer can be a pain. I stick to them, anyway.
    - mattgreenrocks 2y ago
      Yes, this is the way. But I'm fine with short-term cheating when there's no other way because it sticks out a lot more: "wtf, why is the registration endpoint executing hand-written SQL but no other endpoint is?" The fact that it ends up looking conceptually ugly compared to everything else means it is harder to ignore, and people have to justify their sloppiness when getting it merged. > But making sure that I stick to the rules for each layer can be a pain. I stick to them, anyway. It can be. I've found you usually internalize the rules eventually and your mind naturally slots things where they need to go. Then you can aggressively add features/refactor because the surface area is much smaller. It's like learning to work with strong type systems versus fighting them.

ChrisMarshallNY 2y ago

> this is a maintenance nightmare! Yeah, it's a pain to maintain, but it is damn secure.

mattgreenrocks 2y ago
Assuming reasonable factoring, maintenance is only a problem when trying to seriously cheat the layers, eg your controller wants to modify the template engine’s internals for a single request. Better to just be honest about it by punching a hole in the abstraction that is appropriately named and using that.
- ChrisMarshallNY 2y ago
  No cheating! For example, I stop creating SQL, after the first layer above the DB access layer. Everything above that, is a function-based abstraction, so there's no SQL, in most of the stack. Some layers are meant to introduce "replacement points," so you could swap out the SQL for a NoSQL solution, if you want. Most layers have a fair bit of validation and permission-checking, etc. But making sure that I stick to the rules for each layer can be a pain. I stick to them, anyway.
  - mattgreenrocks 2y ago
    Yes, this is the way. But I'm fine with short-term cheating when there's no other way because it sticks out a lot more: "wtf, why is the registration endpoint executing hand-written SQL but no other endpoint is?" The fact that it ends up looking conceptually ugly compared to everything else means it is harder to ignore, and people have to justify their sloppiness when getting it merged. > But making sure that I stick to the rules for each layer can be a pain. I stick to them, anyway. It can be. I've found you usually internalize the rules eventually and your mind naturally slots things where they need to go. Then you can aggressively add features/refactor because the surface area is much smaller. It's like learning to work with strong type systems versus fighting them.