A framework is usually a collection of libraries that work together to serve a greater purpose.
Also if you "plug your code into" anything, a framework or database you:
are making a reverse dependency (now your code cannot exists without the 3rd party dependency)
downgraded the business logic from being the core of your software as it should be, and now the framework is. From this derives other negatives outcomes as well: harder to test, harder to pivot, harder to change the framework/database, spaghetti between the implementation and business.
These are all good reasons for not using opinionated frameworks or put your code in classes that extends a framework class. If you cannot transform your Web API to a CLI api probably you are more "vendor-lock-in" then you have realized.
The framework should be an implementation detail, on the outer layers of your app, like all presenters, databases, repositories and so on. They are all tools, servants of your business (actual problem you try to solve) code.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Not really, for multiple reasons.
A framework is usually a collection of libraries that work together to serve a greater purpose.
Also if you "plug your code into" anything, a framework or database you:
These are all good reasons for not using opinionated frameworks or put your code in classes that extends a framework class. If you cannot transform your Web API to a CLI api probably you are more "vendor-lock-in" then you have realized.
The framework should be an implementation detail, on the outer layers of your app, like all presenters, databases, repositories and so on. They are all tools, servants of your business (actual problem you try to solve) code.