Invasive and Non-Invasive Frameworks in Java
Last Updated :
07 Jun, 2023
There are two categories under which Java technologies or frameworks can be placed:
- Invasive Technologies / Frameworks
- Non-Invasive Technologies / Frameworks
Invasive Framework
Invasive frameworks are those that require application classes to extend framework API-provided classes or implement framework API-provided interfaces while making any framework-based application.
Making application classes that implement or extend from framework-provided API interfaces is restricted. Application classes cannot be moved to another technology or framework to reuse their logic since they are tightly connected with the technology or framework’s API.
In-short invasive frameworks are:
- The developer class will extend or implement an interface given by the framework API.
- Because of extends and implementation, the developer code would be tightly coupled with framework API.
- It won’t promote portability(moving the classes to a new framework would not execute).
- Examples: Servlet, Struts(1.X).
Example Using Java Servlet:
Java
import javax.servlet.*;
import javax.servlet.http.*;
public class MyServlet extends HttpServlet {
protected void doGet(HttpServletRequest request, HttpServletResponse response) {
}
protected void doPost(HttpServletRequest request, HttpServletResponse response) {
}
}
|
Explanation: In the first code snippet, we have an example of an invasive framework using Java Servlets. The MyServlet class extends the HttpServlet class provided by the Servlet API. It overrides the doGet() and doPost() methods to handle GET and POST requests, respectively. The code is tightly coupled with the Servlet API, making it difficult to switch to a different web framework.
Limitation of invasive framework:
Application classes created for invasive frameworks must always be used with such frameworks. We cannot switch to a different framework. If we used Servlet technology when developing our program and better Java technology emerged later, we would be unable to switch to that technology. Our program’s classes are complex classes linked to the Servlet API, not typical classes. We are forced to utilize that Servlet-based program indefinitely, or start from scratch and create another application using new technologies. Once we’ve decided on an invasive framework to build our application, we have to stick with it through the entire process.
Example: JDBC, Servlet, EJB (old), and so on.
Non-Invasive Framework
If there is no limitation on building classes for framework-based applications that implement or extend from framework API interfaces/classes, then such a framework is referred to as a non-invasive framework.
Since the program’s classes in this case are only weakly tied to the technology/framework’s provided API, we may reuse our application logic by moving these classes to another technology/framework. Application classes must be converted to and used with any framework or technology that is comparable before being migrated to non-invasive frameworks or technologies.
In-short non-invasive frameworks are:
- The developer class will not extend or implement any interface given by the framework API.
- No extends and implements keyword, the developer code would be loosely coupled with framework API.
- It promotes portability(moving the classes to a new framework would execute).
- Examples: Spring, JSF, Hibernate, etc. There is no non-invasive Java framework as of now.
Example using Spring Framework:
Java
public class MyService {
private MyRepository repository;
public MyService(MyRepository repository) {
this.repository = repository;
}
public void doSomething() {
repository.saveData();
}
}
|
Explanation: In this code snippet, we demonstrate a non-invasive framework using the Spring Framework. The MyService class is a regular Java class that does not inherit from any framework-specific classes. It accepts a MyRepository dependency via constructor injection. The doSomething() method uses the injected repository to perform an action. This approach allows for the decoupling of code from the framework, making it more flexible and modular.
Please Login to comment...