3 ms·
The problem with this model is that it ends up being an invitation to mix "business" logic with the UI. I look at some of the PHP code I wrote (back when it was
by dhosek 5y ago
The problem with this model is that it ends up being an invitation to mix "business" logic with the UI. I look at some of the PHP code I wrote (back when it was still PHP3) or some of the JSP stuff I've had to work with and this model of development always ends up an unholy mess.
- falcor84 5y agoI wonder if there could be some "gradual" approach here where perhaps you'd have levels of maturity that you can evolve a project thorough over time. Perhaps something such as: 0: no separation of concerns whatsoever, just quickly hacking at it. 1: no separation of concerns required, but you have to label each component as having one or more concerns. This would still allow for mixed "business+presentation", but you can add constraints such as "a pure business component is not allowed to depend on a pure presentation component". 2: No mixed-concerns components allowed. So you have to split them somehow, but they can still interact in arbitrary ways. 3: All interaction across concerns has to go through specific interfaces, such that it's easy to replace implementations (e.g. using dependency injection).