경량 미니 스프링 대안을 만든 이유와 제작 방법

이 짧은 기사에서는 내가 이 라이브러리를 만든 이유를 설명하려고 합니다. 어떻게 구현되나요?

내가 왜 이 라이브러리를 만들었나요?

저는 많은 프로젝트에서 Java EE 프레임워크를 사용하여 작업했으며 대부분의 경우 애플리케이션을 실행하는 데 사용 가능한 리소스에 제한이 없었지만 드물게 리소스, 특히 애플리케이션을 배포 서비스에 배포하기 위한 메모리가 제한되었습니다. 따라서 애플리케이션이 제한을 초과하면 배포 서비스가 처음에는 애플리케이션 속도를 늦춘 다음 계속해서 서비스를 종료합니다. 우리는 스프링 부트도 없이 레거시 스프링 프레임워크를 사용하고 있었고, 다른 라이브러리를 사용하려고 시도했지만 그 차이는 미미하고 쓸모가 없었습니다. 여기서 메모리 소비를 최대한 줄이는 데 초점을 맞춘 경량 스프링 대안을 만들려는 아이디어가 시작되었습니다. .

도서관 디자인을 시작하면서 마음속에 품고 있던 목표는 단 두 가지였습니다.
1 - 메모리 소비를 최대한 줄입니다
2 - 기존 Java EE API를 최대한 사용하여 학습 관점과 전환 자체의 복잡성으로 인해 라이브러리로 쉽게 전환하도록 노력하세요.
그리고 이 두 가지 목표를 통해 내 애플리케이션 중 하나의 메모리 사용량을 약 40% 줄이고 기존 솔루션과 유사하므로 쉽고 빠르게 전환할 수 있었습니다.

이 라이브러리를 어떻게 만들었나요?

읽으면서 코드를 확인할 수 있는 GitHub 저장소가 있습니다.

라이브러리 전체는 많은 부분으로 구성되어 있으며(아래 스크린샷), 대부분의 구현은 메인 모듈에서 이루어지며, 이는 또한 Core, JPA, Web의 세 가지 독립 모듈로 나뉩니다. 앱 모듈은 주로 통합을 위한 것이며, 플러그인 모듈은 라이브러리가 제대로 작동하기 위해 패키지 아카이브 내부에 필요한 파일을 생성하는 데 도움이 되는 Maven 플러그인입니다

핵심 모듈

그래서 우리는 이름에서 알 수 있듯이 종속성 주입 또는 제어 반전이라는 라이브러리의 핵심 기능을 포함하는 핵심 모듈부터 시작하겠습니다.
이 기능을 달성하려면 먼저 컴파일 단계에서 라이브러리가 주석이 달린 클래스에 대한 구성 요소 정의를 생성하기 위해 관리해야 하는 모든 주석이 달린 클래스에 대한 애플리케이션의 클래스 경로를 검색하는 것부터 시작합니다.

구성 요소 정의에는 기본적으로 생성자 정보와 같이 나중에 이 클래스에서 객체를 인스턴스화하는 데 필요한 모든 정보가 포함되어 있습니다. 클래스에 주입 주석이 있는 일부 setter가 있는 경우(생성자와 setter 주입만 지원됨) 일부 인터페이스를 사용하거나 다른 클래스를 확장하면 이 클래스에서 객체를 생성하는 데 필요한 모든 정보를 갖게 됩니다(아래 스크린샷).
그런 다음 모든 클래스 경로 주석을 스캔하고 필요한 모든 구성 요소 정의를 생성한 후 클래스 경로에 JSON 파일로 저장합니다.

핵심 모듈의 두 번째이자 주요 기능은 팩토리 디자인 패턴을 기반으로 하는 종속성 주입 및 제어 역전이므로 ComponentFactoryApplicationContext 인터페이스가 있습니다. > 인터페이스이며 이 인터페이스의 주요 메소드는 구성 요소 이름에서 객체를 반환하는 getComponent 메소드입니다.

JPA 모듈

JPA 모듈의 구현은 스프링 데이터 JPA와 매우 유사하지만 아주 작습니다. 그 이유는 제가 많은 프로젝트에서 스프링 데이터를 사용했고 사용하기 쉽다는 것을 알았기 때문입니다. 앞서 말했듯이 라이브러리가 원활하고 가능한 한 적은 작업이 필요하므로 내 자신의 미니 스프링 데이터 버전을 구현하는 것이 최선의 선택이었습니다.

구현은 저장, 삭제 및 findAll과 같은 데이터베이스에 대한 가장 일반적인 작업을 포함하는 JpaRepository 인터페이스를 중심으로 이루어지며 JPA 모듈을 사용하려면 이 인터페이스를 확장하고 이 인터페이스가 관리해야 하는 엔터티를 제공해야 합니다. ID입니다. 인터페이스를 확장하고 Repository 주석을 추가한 후 메서드를 정의하고 Query 주석으로 주석을 달고 JPQL 쿼리를 제공하면 컴파일 단계에서 라이브러리가 이 인터페이스를 구현하는 완전한 기능을 갖춘 클래스를 생성합니다.

라이브러리는 애플리케이션의 트랜잭션 부분도 관리하므로 모든 저장소 인터페이스와 transactional이라는 주석이 달린 모든 클래스는 트랜잭션 관점에서 라이브러리에 의해 관리됩니다. 따라서 모든 트랜잭션 구성 요소에 대해 라이브러리는 트랜잭션 주석을 기반으로 트랜잭션을 관리하기 위한 프록시를 생성하고 엔터티 관리자 수명 주기도 관리합니다.

웹 모듈

웹 모델은 애플리케이션의 모든 웹 부분을 관리하는 역할을 하며 설계상 독립 모듈이므로 라이브러리의 나머지 모듈과 독립적으로 사용할 수 있습니다. 평소와 같이 일부 모델과 사용법이 매우 유사합니다. Spring web 또는 Jax-rs와 같은 친숙한 Java EE 라이브러리.

구현은 주석을 기반으로 하며 Controller 주석이 달린 클래스가 있고 이 컨트롤러 내에서 PathMapping으로 주석이 달린 메서드를 찾을 수 있으며 이러한 메서드는 특정 경로 또는 특정 경로를 처리합니다. 요청 유형, 콘텐츠 유형 등 일부 기준에 따라 요청합니다.

외부에서는 다른 라이브러리와 매우 유사해 보이지만 내부에서는 다릅니다. 라이브러리가 런타임에 이러한 Controller 클래스를 변경하여 모든 클래스가 BaseHttpServlet을 확장하도록 하기 때문입니다. 은 HttpServlet을 확장하고 일반 서블릿으로 작동합니다.

위 스크린샷에서 볼 수 있듯이 먼저 init 메서드에서 구성 요소를 초기화하여 WebApplicationContext를 사용하여 모든 종속성을 주입한 다음 모든 요청을 처리합니다. handleRequest 메서드를 사용하여 이 컨트롤러에 접근합니다. 이 접근 방식을 사용하면 기존 서블릿 API를 사용하여 컨트롤러를 관리합니다. 이는 라이브러리가 플러그인 역할을 하므로 메모리 공간을 낮게 유지하고 오버헤드도 줄이는 데 도움이 됩니다. 서블릿 API 작업을 보완합니다.

먼저 요청을 올바른 메소드에 매핑하려고 시도한 다음 요청과 같은 HttpServletRequest 또는 컨텍스트에서 정보를 가져와 메소드 내부에 요청된 모든 정보를 삽입하려고 합니다. 매개변수, 헤더, 경로 변수, 요청 본문...

이 모든 정보를 변환한 다음 요청 시 메서드에 매개변수로 삽입한 다음 메서드를 실행하고 PathMapping 생성 또는 콘텐츠 유형에 따라 결과 또는 결과를 변환합니다(by 기본값은 application/Json) 그런 다음 HttpServletResponse.

마지막으로 프로세스에 문제가 발생하여 오류가 발생한 경우 이 오류나 예외를 포착하고 예외 유형에 따라 처리하려고 합니다. 다양한 유형의 예외를 처리하는 예외 핸들러가 있습니다. 사용자는 원하는 방식으로 예외를 처리하기 위해 더 많은 핸들러를 제공할 수도 있습니다.

메이븐 플러그인

마지막으로 중요한 부분은 애플리케이션이 제대로 작동하고 jar 또는 war 패키지를 빌드하는 데 필요한 모든 파일을 생성하는 Maven 플러그인입니다.
먼저 플러그인은 클래스 경로와 종속성을 검색하여 comComponent-definitions-json 파일을 검색하고, 이 파일에서 다음을 생성합니다.
lazy-application.json: 애플리케이션에 대한 모든 구성 요소와 해당 종속성을 포함합니다

lazy-application.properties: 컨트롤러 및 엔터티 목록이 포함되어 있으므로 런타임 시 클래스 경로를 검색할 필요가 없습니다.
마지막으로 포장이 jar인 경우 메인 클래스를 가져옵니다.

마지막으로 종속성이 있는 애플리케이션 코드와 이전 단계에서 생성한 파일이 포함될 패키지 아카이브 파일을 빌드합니다.

기사를 짧게 유지하고 이해하기 너무 복잡하지 않게 자세하게 설명하지 않으려고 노력했습니다. 물론 코드는 GitHub에서 사용할 수 있으므로 직접 사용해 볼 수도 있습니다. 질문이 있는 경우 아래에 남겨주시면 시도해 보겠습니다. 답변을 드리겠습니다.

위 내용은 경량 미니 스프링 대안을 만든 이유와 제작 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!