No matter what the language direction, generally speaking, a framework is too intrusive, which is a voice of criticism, so I guess it is not because of this that non-intrusive has become a "selling point" of publicity.

For example, spring and struts 2 use annotations, configuration files, conventions or reflection (other languages may be other ways) to achieve non-invasive, and the compilation and operation does not have formal dependence on the framework API.

But in essence, without this framework, our program simply cannot run correctly. These so-called annotations are customized. When and how they are processed are different. Think about the migration from gson to Jackson. The migration has costs and risks. Do you need users to write a new one?

In addition, how high is the probability of real migration? It feels very small.

CodePudding user response：

The question seems to be based on a very broad definition of what it means to be non-invasive. "Non-invasive" meant something very specific to those of us who transitioned to DI frameworks from earlier solutions. This wasn't about compile time dependencies on framework code, and it wasn't about being able to migrate to another framework (we'd already found out what the promises of EJB vendors about compatibility were worth). The problem we faced was how to write unit tests of application code that could test the business logic while being easy to set up and able to run quickly.

Enterprise applications using EJB faced huge hurdles getting tests to run. We had applications full of components that could not be exercised without running them in an EJB container. Tests were hard to set up, they took a long time to run, and when tests broke it was more likely to be due to an environment or configuration issue than a problem with the code being tested.

Non-EJB applications weren't great either, the usual architecture for these applications used the Go4 Singleton pattern pervasively, including in implementing Service Locators. These singletons used static references and the classloader to enforce their singleton-ness, and there was no good way to mock them out. Some places implemented their singletons using a custom configuration for tests to avoid having the tests trigger unwanted behavior, which mean tests could run safely but there was more work implementing the singletons and configuring was needed for the tests.

My practical test for whether something is invasive or not is, can I write a unit test for just the functionality I want to exercise and not get sucked into dealing with infrastructure, configuration, or dependency issues, where things outside the immediate area of what I care about are imposing themselves on me? By that standard, Spring is non-invasive. I can easily write tests that mock their collaborators and exercise just the logic I care about.

So that is how I reason about it based on my own definitions. If you want to make your own case based on your own ideas, my advice is to 1) define your terms and 2) provide a test of whether something meets your standard based on something you need to do (the more practical the better for your argument).

CodePudding user response：

I think your question is very interesting but a little subjective..

My thought is that we must be build applications that are robust to changes, but remain pragmatic. We need to find the good point between abstraction and implementation (as described in the Clean Architecture book).

In the Java eco-system, The standard JSRs is very often defined around interfaces and not implementations, offering you a good way to avoid tight coupling to a specific framework (ex: JPA instead of Hibernate, JAX-RS instead of Jackson..).

In the Spring ecosystem, you can use these standards annotation (@Inject vs @Autowired), and it will work perfectly, but you will often loose some functionalities offered by the implementations.

Some architectures tends to separate totally the layers between your business code and the framework code (the hexagonal architecture call it the infrastructure and application layers), but it comes at a price..

The probability of this type of migration is unknown and depends on the changing needs of your project (I've never encountered a change of JPA vendor implementation). But I believe that with the most active project (Hibernate, Jackson..), you can try to reduce it.

So... Be pragmatic :)