4 ms·

Keeping code clean doesn't mean architectural perfection. It means architectural consistency. So, if your controllers talk directly to your database, great! Jus

by cheez 7y ago

Keeping code clean doesn't mean architectural perfection. It means architectural consistency. So, if your controllers talk directly to your database, great! Just make sure it's easy to do and doesn't involve too much boilerplate.

bluGill 7y ago
Clean code means architectural perfection where it matters. Should the controllers talk directly to a database or have an abstraction? I can make either argument, which is right depends on your problem. Plan to switch databases (for testing, you don't trust your vendors, or your customers demand different ones), then the abstraction is required. If everything else is locked into the 40 year old database (which isn't normalized because that concept was just an academic idea with no real world use back then) then there is no way you will change anyway so maybe you don't need it. Or maybe it is the other way around - good sql "should be" portable to any database, while the non-normalized database needs the abstraction to ensure all the constraints are kept sane. I just put forth 4 different arguments for a simple choice, but before you decide which is right for you need to figure out if this isn't some other consideration my arguments didn't cover.
- mumblemumble 7y ago
  There's also more than one way to carve up the architecture. I do think that we humans need slices in order to mentally compartmentalize and be able to work with manageable bits. But there's no reason I can think of to systematically prefer vertical slices or horizontal slices. Horizontal slices give you something like the classic monolithic three-layer architecture, and vertical slices give you more of a component-based approach. The big trick is to know which approach you're using, and stick to it. In a layered architecture, you absolutely do not skip layers, but it's generally fine to have one layer talk to pretty much any part of a neighboring layer. In a component-oriented architecture, it's really not a big deal IME to let controllers talk directly to the database, just so long as you never let one component directly access another component's schema. You get data out of other components by talking to their public interfaces. As long as you color within those lines, things won't get too tangled. If you're really worried, I suppose you could try doing both vertical and horizontal splits, but my impression is that that always places the application at risk of collapsing under the weight of its own bureaucracy.
  - bluGill 7y ago
    I generally think you have several levels of architecture.you might go vertical at the high level and then delegate each slice to more junior architects who do different things in their slice. Of course this depends on the size of the project too.
- cheez 7y ago
  Exactly, a lot of people assume that any of those options aside from the strict layering is "unclean" code. Clean code is code that is easy to read, easy to modify and more or less DRY. The rest is dressing.
- AnimalMuppet 7y ago
  Yeah. Experience teaches you that "it depends" is the correct answer to a whole lot of questions. And it hopefully teaches you to have some wisdom for deciding which side of "it depends" is the best answer for your situation.

by cheez 7y ago

bluGill 7y ago

Clean code means architectural perfection where it matters. Should the controllers talk directly to a database or have an abstraction? I can make either argument, which is right depends on your problem. Plan to switch databases (for testing, you don't trust your vendors, or your customers demand different ones), then the abstraction is required. If everything else is locked into the 40 year old database (which isn't normalized because that concept was just an academic idea with no real world use back then) then there is no way you will change anyway so maybe you don't need it. Or maybe it is the other way around - good sql "should be" portable to any database, while the non-normalized database needs the abstraction to ensure all the constraints are kept sane. I just put forth 4 different arguments for a simple choice, but before you decide which is right for you need to figure out if this isn't some other consideration my arguments didn't cover.

mumblemumble 7y ago
There's also more than one way to carve up the architecture. I do think that we humans need slices in order to mentally compartmentalize and be able to work with manageable bits. But there's no reason I can think of to systematically prefer vertical slices or horizontal slices. Horizontal slices give you something like the classic monolithic three-layer architecture, and vertical slices give you more of a component-based approach. The big trick is to know which approach you're using, and stick to it. In a layered architecture, you absolutely do not skip layers, but it's generally fine to have one layer talk to pretty much any part of a neighboring layer. In a component-oriented architecture, it's really not a big deal IME to let controllers talk directly to the database, just so long as you never let one component directly access another component's schema. You get data out of other components by talking to their public interfaces. As long as you color within those lines, things won't get too tangled. If you're really worried, I suppose you could try doing both vertical and horizontal splits, but my impression is that that always places the application at risk of collapsing under the weight of its own bureaucracy.
- bluGill 7y ago
  I generally think you have several levels of architecture.you might go vertical at the high level and then delegate each slice to more junior architects who do different things in their slice. Of course this depends on the size of the project too.
cheez 7y ago
Exactly, a lot of people assume that any of those options aside from the strict layering is "unclean" code. Clean code is code that is easy to read, easy to modify and more or less DRY. The rest is dressing.
AnimalMuppet 7y ago
Yeah. Experience teaches you that "it depends" is the correct answer to a whole lot of questions. And it hopefully teaches you to have some wisdom for deciding which side of "it depends" is the best answer for your situation.