Java 프레임워크의 용도는 무엇입니까?-java지도 시간-php.cn

이제 모든 프로젝트는 프레임워크를 사용합니다. 이제 매우 일반적인 프레임워크는

SSH(Struts+SpringMVC+Spring+Hibernate),SSM(Struts/springMVC+Spring+Hibernate)

로그인 후 복사

입니다. 최근 프로젝트 itoo에서 사용된 프레임워크는 easyUI+SpringMVC+EJB+hibernate입니다. 프로젝트 계층화의 목적은 계층화를 더 효과적으로 분리하기 위한 것입니다. 왜 그렇게 많은 프레임워크가 필요하지 않습니까?

Java 프레임워크의 용도는 무엇입니까?

그리고 이제 회사의 많은 웹 프로젝트의 제어 계층의 기술 프레임워크가 struts2에서 springMVC로 마이그레이션되었습니다. 이제 개발을 위해 서블릿과 jsp 같은 기술을 사용하는 대신 struts2나 springMVC 같은 프레임워크를 선택하시겠습니까?

특히 우리 웹의 프런트엔드 페이지는 JSP를 버리고 Velocity와 같은 템플릿 언어를 사용하여 개발되고 있는데, 이러한 선택이 우리의 Java 웹 개발에 어떤 이점을 가져올까요? 나는 또한 많은 Java 엔터프라이즈급 개발자가 왜 스프링 프레임워크를 선택하는가라는 새로운 질문을 발견했습니다. 스프링 프레임워크는 우리가 개발하는 애플리케이션에 무엇을 가져오는가?

깊이 생각해 보니 전혀 이해가 되지 않더군요. 결국에는 제가 익숙하고 흔히 사용한다고 생각했던 기술들이란 것을 알게 되었습니다. 낯설고 이해하기 어려운 곳이 더 높은 수준에서 사용할 수 있는지 여부가 관건입니다. 그러나 오랜 세월 축적된 결과 struts2 및 spring과 같은 기술은 상당히 크고 복잡해졌습니다. 매우 광범위합니다. 오랫동안 사용해왔지만 아직 익숙하지 않고 불분명한 기술이 많이 있습니다.

프레임워크를 사용하면 매우 일반적인 이점이 있습니다. 첫째, 개발 프로세스 속도를 높일 수 있습니다. , 유사한 프로젝트에서 코드를 재사용하면 개발자의 시간과 에너지가 절약됩니다. 프레임워크는 지루한 코딩 작업을 수행하기 위해 사전 구축된 모듈을 제공합니다.

이 이점은 모든 프레임워크에 매우 적용 가능합니다.

사실 소프트웨어에는 한 종류의 훌륭한 프레임워크가 많이 있습니다. 기존 기술을 기반으로 하며 기존 기술과 동일한 비즈니스 기능을 제공한다는 것이 특징입니다. 더 사용하기 쉽고, 더 강력하고, 더 강력한 기술.

예: 이 기사에서 논의되는 jQuery, struts2 및 springMVC 이러한 프레임워크는 매우 복잡하지만 실제로는 단 하나의 장점만 있습니다. 사용자는 핵심 비즈니스 개발에만 관심을 가질 수 있습니다. 프레임워크는 기술 및 비즈니스 개발과 관련이 없는 다양한 기술적 문제를 원래대로 보호하는 데 도움이 됩니다. jQuery, struts2 또는 springMVC와 같은 프레임워크가 우수한 이유는 이러한 기능을 너무 잘 수행하여 이를 사용하는 많은 프로그래머가 더 이상 원래 기술의 본질을 알지 못하기 때문에 struts2를 더 잘, 더 능숙하게, 깊이 있게 이해해야 하기 때문입니다. 여기에서 우리는 struts2 기술에서 벗어나 struts2 기술의 원천인 servlet으로 가서 서블릿의 특성을 주의 깊게 연구해야 합니다. 그래야만 struts2 프레임워크를 더 잘 배울 수 있습니다.

서블릿의 기능은 브라우저에서 서버로 요청을 받고, 서버에서 처리한 응답을 사용자의 브라우저로 반환하는 것입니다. 브라우저와 서버는 요청한 내용을 브라우저가 조립하는 과정을 거칩니다. http 메시지는 http 프로토콜 메시지의 사양에 따라 사용자의 선택과 관련 정보에 따라 네트워크를 통해 지정된 서버로 전송되고, 서버는 특정 웹 컨테이너를 통해 메시지 정보를 수신합니다.

예: tomcat, jetty 및 jboss와 같은 웹 컨테이너는 http 메시지를 구문 분석합니다. 사용자 요청인 경우 최종 구문 분석된 메시지 정보가 요청 개체에 저장되고 서버는 이를 사용합니다. 이 요청에 대한 처리가 완료된 후, 서버 프로그램은 결과 정보를 응답 개체에 캡슐화한 다음 웹 컨테이너에 응답 개체를 전달하여 http 프로토콜의 메시지를 보냅니다. 브라우저는 최종적으로 응답 메시지를 구문 분석하고 최종 결과를 사용자에게 표시합니다.

웹 컨테이너는 서블릿 인터페이스를 만들었습니다. 서블릿 인터페이스는 개발자가 자신의 비즈니스 로직을 구현하는 곳입니다. 서블릿을 개발하는 프로그래머는 빈칸 채우기 질문 및 채우기의 컨텍스트 또는 컨텍스트 프롬프트를 수행하는 것과 같습니다. -blank questions은 요청 및 응답 개체이지만 javaEE 사양의 서블릿 인터페이스는 init, service 및 destroy 세 가지 메소드만 포함하여 매우 간단합니다. 그러나 이 인터페이스는 너무 일반적이므로 사양에서는 HttpServlet 클래스도 제공합니다. http 요청 유형에 따라 doGet, doPost 등의 메소드를 제공합니다. 서블릿 인터페이스 가장 큰 특징은 http 프로토콜의 특성을 기반으로 정의된다는 점입니다. 따라서 사용자가 http 프로토콜의 특성에 특히 익숙하지 않은 경우. 서블릿을 개발할 때, 특히 복잡하고 특별한 요청이 있을 때 다소 혼란스러운 문제에 직면하게 됩니다. 시간:

예를 들어, 파일 업로드는 브라우저에 특수 파일 형식을 반환합니다. 이때 서블릿 개발을 사용하는 것은 그리 편리하지 않습니다. 서블릿 개발에는 종종 간과될 수 있는 또 다른 문제가 있는데, 바로 유형 변환입니다. 요청된 데이터의 http 프로토콜 전송은 모두 텍스트 형식이며 웹 컨테이너에서 구문 분석한 후 통화, 숫자, 날짜와 같은 유형이 발생하면 변환해야 합니다. 페이지에서 많은 정보를 전송하는 경우 많은 유형 변환을 수행해야 하며 이러한 작업은 기술적인 내용이 없고 수동 작업이므로 프로그램 오류가 발생하기 쉽습니다.

동시에 Java Enterprise 개발은 모두 JavaBeans를 중심으로 이루어지며, 유형 변환된 데이터는 해당 JavaBeans에 캡슐화되어야 합니다. 이런 종류의 작업은 확실히 프로젝트 개발에 좋지 않습니다. 따라서 고대 struts1은 이러한 작업을 특별히 담당하는 DTO 개체(데이터 전송 개체)를 정의하는 이 문제에 대한 해결책을 찾았습니다. 그러나 struts2에서는 서블릿 자체를 대체하는 전체 작업이 javabean입니다. .

Java Enterprise 개발의 기술적 특징 중 하나는 javabeans를 사용한다는 것입니다. struts2의 특징 중 하나는 서블릿을 대체하는 작업 클래스가 일반적인 javabean이라는 것입니다. 먼저 struts2 프레임워크는 유형을 변환합니다. 캡슐화 후에는 요청 정보가 이 javabean의 속성에 캡슐화되므로 웹 프로그램을 개발할 때 발생하는 유형 변환 및 캡슐화 문제를 앞서서 전통적인 서블릿이 다음과 같이 정의한다고 언급했습니다. http 프로토콜이며 요청 방법(게시 또는 가져오기 방법)에 따라 사용자의 요청을 처리합니다.

그러나 프로그램 개발자의 경우 요청, 특히 URL은 실제로 서버가 외부 세계에 제공하는 기능이거나 서블릿을 사용하여 개발하는 경우 서버 측에서 수행하는 작업입니다. 프로그램을 만들려면 http 액션을 특정 비즈니스 액션으로 변환해야 하는데, 이는 프로그램 개발을 번거롭게 하고 개발 난이도를 증가시킵니다. 따라서 struts2는 서블릿의 javabean을 대체하고 서블릿에서 메소드 변환과 특정 비즈니스에 관해 http 요청을 차단합니다. Actions에서 Javabeans의 모든 메소드는 각 URL 요청에 대응할 수 있으므로 개발의 어려움이 필연적으로 줄어듭니다.

서블릿의 또 다른 기능은 페이지가 올바른 응답을 얻을 수 있도록 응답 개체를 구성하는 것입니다. 실제로 최신 브라우저는 텍스트, 사진, 비디오 등을 표시할 수 있습니다. 리소스가 다르면 http 응답 메시지가 달라집니다. 서블릿 개발을 사용하면 리소스에 따라 Java 프로그램에서 하드 코딩된 처리를 사용해야 하며, 프로그래머가 이를 사용하는 경우에는 다른 작업을 수행해야 합니다. 리소스 처리에 대한 부적절한 이해는 문제를 야기합니다. Struts2는 이 로직을 구성 파일 형태로 Java 프로그램에서 분리하고 구성을 사용하여 통합 관리합니다. 결과 처리 방법을 더욱 통일화하고 관리하기 쉽게 만듭니다. 또한 프로그램의 견고성을 향상시키고 개발의 어려움을 줄여줍니다.

MVC 개발 모델의 서블릿은 컨트롤 레이어인 C 레이어입니다. 컨트롤 레이어는 러시아 쌍두 독수리(한 머리는 동쪽을 보고 다른 하나는 서쪽을 보임)와 같습니다. 다른 머리는 M 레이어를 봅니다. 모델 레이어를 보면 V 레이어의 뷰 레이어를 보면 모델 레이어도 Java로 작성되어 있고 컨트롤 레이어도 서버 측 언어로 개발되어 있습니다. M 레이어와 C 레이어 사이의 통신에는 자연스러운 장애물이 없지만 V 레이어 뷰 레이어에는 자연스러운 장애물이 없습니다. 이는 브라우저의 경우 HTML, JavaScript 및만 이해합니다. CSS는 Java의 내용을 이해할 수 없지만 서버는 브라우저에서 이해하고 승인해야 합니다.

따라서 Java 정보를 HTML 페이지로 변환하는 기술이 필요합니다. 이는 javaEE 사양에서 제공하는 JSP 기술이지만 실제로는 클라이언트 측 기술이 아닌 서버 측 기술입니다. 초기 jsp 개발에서는 java 코드가 페이지에 직접 작성되었지만 나중에 javaEE 사양에서는 html 태그와 유사한 방법을 사용하여 사용자 정의 태그 기술을 제공했습니다. Java 코드를 구문 분석하면 struts2 프레임워크는 완전한 사용자 정의 태그 기술 세트를 제공합니다. 이는 별로 들리지 않을 수도 있지만 그 효과는 특별합니다. 사용자 정의 태그를 사용자 정의라고 부르는 이유는 A가 아니더라도 모든 사람이 스스로 정의할 수 있기 때문입니다. 사양은 필연적으로 혼란을 야기할 것이며 완전한 맞춤형 태그 세트는 우리가 직접 새로운 개발 언어를 정의하는 것과 같습니다. 프로그래머는 이 말을 들으면 확실히 개발의 어려움을 이해할 것입니다. 사용자 정의 태그의 전체 세트는 상상할 수 없으며 사용자 정의 태그는 제어 계층과 밀접하게 연결되어 있어 어려움에 또 다른 차원을 추가하므로 struts2에서 제공하는 사용자 정의 태그는 향후 비즈니스 개발에 큰 도움이 될 것입니다. 질적 도약.

서블릿에는 리스너와 필터라는 두 가지 중요한 기술이 있습니다. 리스너가 웹 개발에 사용되는 경우는 비교적 적습니다. 이 기술은 대부분의 웹 개발에서는 무시됩니다. 가장 일반적으로 사용되는 리스너는 ServletContext의 생성 및 삭제를 위한 리스너일 수 있습니다. ServletContext는 웹 애플리케이션 전체의 전역 개체이므로 이 리스너를 사용하여 초기화하고 삭제합니다. 스프링 컨테이너의 초기화 작업과 같은 웹 애플리케이션의 전역 정보입니다. 더 흥미로운 점은 struts2에 인터셉터가 있다는 것입니다. 이들은 동일한 기능을 갖고 있으며 요청을 가로채는 데 사용됩니다. 인터셉터는 struts2의 고유한 기능이므로 실제로는 필터를 사용하는 것보다 인터셉터를 사용하는 것이 더 편리합니다. , 인터셉터가 사용하는 기술은 필터보다 더 발전했습니다. 인터셉터는 반사 기술을 사용하기 때문에 인터셉터는 더 넓은 영역을 차단하고 요청을 제어하는 능력이 더 강하며 완료할 수 있는 작업이 더 다채롭습니다.

내가 처음으로 struts2를 접한 것은 gxpt 시스템에서였습니다. 누군가 Struts 설계의 목적 중 하나가 제어 계층에서 요청 및 응답 객체의 작동을 차단하는 것이라고 말했습니다. http 프로토콜의 이 두 아들은 웹 개발에 혼란을 야기할 수 있지만, 실제 개발에서는 이 두 개체를 무의식적으로 사용하는 경우가 많습니다. struts2에는 너무 많은 반사 메커니즘이 사용됩니다. 특히 구성에 주석을 사용하는 경우에는 Java에서 반사의 실행 효율성이 매우 낮습니다. 서블릿을 직접 사용하면 웹 애플리케이션의 실행 효율성이 확실히 향상됩니다. 사실 당시에는 서블릿에서 스프링 기술을 유연하게 사용할 수 없었기 때문에 이 작업이 어려웠습니다.

spring 기술은 Java Enterprise 개발에서 가장 중요한 기술이라고 할 수 있지만 Spring의 역할과 중요성을 실제로 이해하는 것은 실제로 많은 사람들이 사용법 측면에서만 이해하기가 정말 어렵습니다. 단계(예: 선언적 트랜잭션은 사용하기 쉽습니다 등), 오늘날의 Spring 기술 생태 환경은 훌륭하고 Spring은 모든 것을 포괄하며 그 내용은 원래 Java 언어와 다르지 않으며 Spring은 매우 큰 상자가 구축됩니다. IOC 및 AOP 기술에 대해 이 두 기술을 깊이 이해해야만 Spring 상자가 왜 그렇게 많은 것을 담을 수 있는지 이해할 수 있습니다.

첫 번째는 ioc입니다. ioc 기술에 대한 첫 번째 설명은 제어 반전이라고 합니다. 또 다른 설명은 종속성 주입입니다. 이 두 이름은 문자 그대로 이해하기 어렵지만 원리를 이해하면 알 수 있습니다. 그들의 설명은 정확합니다. IOC 기술의 핵심은 객체를 생성하는 기술, 즉 클래스를 객체로 인스턴스화하는 기술인데, 자바에서는 새로운 클래스가 생성될 때마다 a를 통해 클래스를 인스턴스화한다. 새로운 인스턴스 객체가 생성될 것입니다. 이렇게 하면 매우 낭비적인 것처럼 보이며 때로는 프로그램을 개발할 때 현재 하나의 인스턴스 객체만 생성할 수 있는 특정 클래스만 필요하기 때문에 때로는 매우 위험합니다. 또한, 디자인 모드에서는 객체를 생성하는 팩토리 메소드를 전달할 수도 있습니다. Spring을 사용하는 사람들은 위의 내용을 보면 알 수 있습니다. one-to-one 범위 속성은 싱글톤 객체를 생성하고, 프로토타입은 새로운 객체를 생성합니다.팩토리 메소드는 객체를 생성하는 도구라고 할 수 있습니다. 객체지향 프로그래밍에서 객체는 실제 개체를 표시하는 것과 동일합니다.

예를 들어, 헌팅 작업을 완료하는 데 사용되는 객체가 있습니다. 사람과 총이라는 물건을 사람과 총에게 주어 사냥개체로 사냥 작업을 완료할 수 있게 하는데, 여기서는 사람과 총이라는 물건을 만드는 것이 생각보다 간단하지 않다. 예를 들어 총을 만들려면 금속과 공작 기계가 필요하며 공작 기계와 총알은 두 개의 새로운 개체가 하나씩 중첩되어 있고 서로 연관되어 있습니다. Java 코드에서 총 개체를 생성하는 경우 간단한 총 개체가 아니라 더 복잡한 항공모함을 생성하는 경우 이러한 개체의 중첩 및 상호 의존성을 제거하는 방법은 상상할 수 없습니다.

spring은 Spring이 컨테이너를 제공하는 방식을 제공하며, xml 파일에서 각 개체의 종속성을 정의하고 컨테이너는 개체를 사용해야 할 때 완료합니다. 우리 자바 코드에서는 특정 인스턴스를 얻으면 컨테이너에서 얻을 수 있고 객체의 구성 작업은 스프링 컨테이너에 의해 인수되므로 이를 제어 역전이라고 합니다. Java 프로그램에서 객체를 작성하는 기능은 컨테이너에 넘겨집니다. 인수 및 종속성 주입은 프로그램이 객체를 사용하려고 할 때 컨테이너가 이를 프로그램에 주입하는 것을 의미합니다.

Java 개발에서는 특정 클래스에서 제공하는 함수를 사용하고 싶습니다. 하나는 새 클래스를 생성하고 새 클래스는 해당 클래스를 상속하는 것입니다. . 그러면 두 클래스 사이에 연관 관계가 설정됩니다. Spring의 ioc 컨테이너는 이 연관 관계를 구현합니다(상속 관계가 아님을 기억하세요). 그러면 특정 클래스를 새 클래스에 할당하는 방법은 무엇입니까? 일반적으로 두 가지 유형만 있습니다. 하나는 생성자를 통한 것이고 다른 하나는 setXXX 메소드를 통한 것입니다. 이는 스프링 컨테이너에서 사용되는 두 가지 표준 주입 방법입니다.

위에서 언급한 상속 방법이든 연결 방법이든 실제로는 대상 객체의 기능을 향상시키기 위한 개발 방법입니다. 디자인 패턴에는 프록시 모드가 있습니다. 프록시 모드는 상속 패턴과 연관 패턴의 조합이지만 이 콤플렉스의 기능은 객체 주입 문제를 해결하는 것이 아니라 특정 작업 객체에 대한 보모 또는 비서를 찾는 것과 같습니다. 소설 속 2번 보스. 이 2번 보스는 2번 리더를 통해 외부 세계로의 특정 인스턴스 개체를 나타냅니다. 리더, 1등 리더는 큰 일을 해야 하기 때문에 일부 거래적이고 반복적인 작업 예를 들어 차를 끓이고 차를 정리하는 일은 1등 리더가 귀찮게 할 필요가 없는 작업이지만 1등 리더가 처리합니다. 2. AOP는 핵심 비즈니스와 관련이 없는 프로그램 개발의 트랜잭션 문제를 해결하지만, 실제 개발에서는 이러한 문제가 필요한 방식이기도 합니다. 코드를 저장합니다.

Spring의 핵심 기술의 핵심은 커뮤니케이션 메커니즘입니다. Spring은 항상 양측 간의 통신 비용을 줄이면서 정보 흐름을 유지하기 위해 최선을 다합니다. 실제 조직에서는 커뮤니케이션을 잘하는 사람이 있어야 합니다. 회사의 리더. 소통을 잘하는 리더는 다양한 자원의 열정을 동원할 수 있다. 소통을 잘하는 리더는 모든 강물에 열려 있고 모든 사람들이 그를 따르게 할 것이다. 큰 상자라 모든 것을 넣을 수 있습니다.

봄은 은행과 매우 유사합니다. 물질적 부를 직접 창출할 수는 없지만 모든 자원이 이를 통해 순환되어야 합니다. 프로그램의 세계로 돌아가서 봄의 역할은 다음과 같습니다. 프로그램 간의 링크 디커플링, 스프링은 서로 다른 모듈 간의 결합을 줄일 수 있습니다. 그 이유는 프로그램 개발에서 객체 전송을 통해 서로 다른 모듈 간의 정보 통신이 완료되고 객체가 원활하게 전송될 수 있는지 여부는 합리적인 구성에 달려 있기 때문입니다. 좋은 객체 구성 방법은 객체 전송을 잘 관리할 수 있다는 것이 스프링이 시스템 아키텍처 설계에 제공하는 이점입니다.