| I've had extensive experience on both sides of the fence -- working on apps within existing frameworks, and also maintaining custom frameworks & libs for apps using those. Unfortunately I find this article of very little value. The author's claimed idea of "decoupling from the framework" is generally ineffective & impractical. It leads to extra layers of adapters & SPI with high cost and almost always zero value. These sure add bloat & make the codebase pointlessly difficult to navigate, but are improbably unlikely to ever add value in allowing the framework to actually be changed. Difficulties include mismatched abstractions, endless adapter layers, parameter types for methods also all needing to be abstracted, restricted capabilities, difficulty conveying behaviour/ dynamism rather than static values, and -- of course -- poor performance. Results are severe choke-points hindering functionality, broken abstractions where stuff actually had to be done, and 90% of the SPI abstractions turning out worthless if you ever did try to migrate to another framework. I'm an architect. I've seen people's non-portable abstractions so many times. The article's advice just seems so unlikely to help. Pick a framework that offers long-term maintainability and lets you separate out your domain model & business logic, and just code directly in it. Rather than railing against bad frameworks from limited experience (perhaps in rickety languages too), the author should perhaps spend some time to find a good one. Spring is fine for many purposes. The MVC is coupled at the front, but your domain model need not & should not be. Focus on that, which should be your business value. |