| ▲ | delusional a day ago | |
> Lack of layer separation becomes a problem in the long term. When you're just starting out, it may seem like overengineering, but it isn't I actually agree, but you're setting of a false dichotomy. I do believe in strong layering at the interfaces, for exactly the reasons you line up. What I don't believe in is what I might call "struct annotation based parsing" at those interfaces. Typically, you don't want to pass DTO's around your code. Usually, you take in that struct, and then immediatly have some code to poke it into the appropriate places in your actual data structures. It's very often much easier to simply take a well structured but more direct and generic interpretation of the input data, and write the code to poke it into the correct places directly. It is not that you should define your inputs separately from your internal data storage. It's that the specification of your input structure shouldn't exist as a struct, it should exist as the consequence of your parsing code. > When you're just starting out, it may seem like overengineering, but it isn't It's a real shame that the internet has driven us to assume everybody is a novice. | ||
| ▲ | kgeist a day ago | parent [-] | |
>It's a real shame that the internet has driven us to assume everybody is a novice. Sorry, English is not my native language. I didn't mean to say you're a novice. >Usually, you take in that struct, and then immediatly have some code to poke it into the appropriate places in your actual data structures >It's that the specification of your input structure shouldn't exist as a struct, it should exist as the consequence of your parsing code. >It is not that you should define your inputs separately from your internal data storage. It's that the specification of your input structure shouldn't exist as a struct, it should exist as the consequence of your parsing code. Can you give an example? | ||