반응형

스프링과 스프링부트 차이 (spring vs spring boot)

1. 설정 및 구성:

스프링: 스프링 프레임워크는 다양한 기능을 제공하지만, 이를 설정하는 데 많은 XML 구성 파일이나 Java 설정 클래스가 필요합니다. 개발자가 직접 빈(bean)을 정의하고 연결해야 하므로 초기 설정이 복잡할 수 있습니다.

스프링부트: 스프링부트는 자동 설정(autoconfiguration)을 통해 대부분의 설정 작업을 자동화합니다. 기본적인 프로젝트 설정과 함께 필요한 대부분의 의존성을 자동으로 구성해주기 때문에 설정 작업이 크게 줄어듭니다.

2. 프로젝트 구조 및 시작:

스프링: 스프링 프로젝트를 시작하려면 각종 라이브러리를 수동으로 추가하고 설정해야 합니다. 초기 세팅에 많은 시간이 걸릴 수 있습니다.

스프링부트: 스프링부트는 스타터 프로젝트(starter project) 개념을 도입하여 필요한 라이브러리를 쉽게 추가하고 설정할 수 있게 합니다. Spring Initializr와 같은 도구를 통해 몇 번의 클릭만으로 프로젝트를 생성할 수 있습니다.

3. 내장 서버:

스프링: 스프링에서는 애플리케이션을 실행하기 위해 별도의 서버(Tomcat, Jetty 등)를 설치하고 설정해야 합니다.

스프링부트: 스프링부트는 내장된 톰캣(Tomcat), 제티(Jetty), 언더토우(Undertow) 서버를 제공하여 별도의 서버 설치 없이 애플리케이션을 바로 실행할 수 있습니다.

4. 개발 생산성:

스프링: 강력하고 유연한 기능을 제공하지만, 설정과 구성이 복잡할 수 있어 초기 학습 곡선이 가파를 수 있습니다.

스프링부트: 설정의 단순화와 자동 구성을 통해 개발 생산성을 크게 향상시켜 줍니다. 코드 작성을 더 빠르고 간단하게 만들기 때문에 빠른 프로토타이핑과 개발이 가능합니다.

 

 

스프링 war 배포 vs 스프링부트 jar 배포

스프링(Spring) 애플리케이션을 사용할 때, 전통적으로 WAR 파일을 사용하여 배포하는 것이 일반적이었습니다. 이는 특히 스프링이 처음 등장했던 시절부터 많이 사용되었던 방식입니다. 하지만 최근 몇 년 동안 스프링부트(Spring Boot)의 등장으로 인해 JAR 파일로 배포하는 방식이 더 인기를 끌고 있습니다.

 

전통적인 스프링 애플리케이션과 WAR 파일

 

1. WAR 파일 사용 이유:

서버 배포: 전통적인 스프링 애플리케이션은 Tomcat, Jetty, JBoss 등과 같은 웹 애플리케이션 서버에 배포되었습니다. 이 서버들은 WAR 파일을 배포 유닛으로 사용합니다.

관리 및 스케일링: 여러 애플리케이션을 하나의 서버에서 관리하고 스케일링할 수 있는 장점이 있습니다.

2. WAR 파일 배포 과정:

애플리케이션 코드를 작성하고, 이를 WAR 파일로 패키징합니다.

WAR 파일을 웹 애플리케이션 서버의 특정 디렉토리에 배포합니다.

서버가 WAR 파일을 인식하고 애플리케이션을 실행합니다.

 

스프링부트와 JAR 파일

 

스프링부트는 전통적인 스프링 애플리케이션의 복잡성을 줄이고, 보다 단순하게 애플리케이션을 개발하고 배포할 수 있게 도와줍니다. 이 과정에서 JAR 파일 배포가 주로 사용됩니다.

 

1. JAR 파일 사용 이유:

독립 실행형 애플리케이션: 스프링부트는 내장 톰캣(Tomcat) 등을 포함하여 JAR 파일 형태로 패키징되므로, 별도의 웹 애플리케이션 서버 없이 독립적으로 실행할 수 있습니다.

간편한 배포: JAR 파일 하나로 애플리케이션을 쉽게 배포하고 실행할 수 있어 배포 과정이 단순화됩니다.

2. JAR 파일 배포 과정:

애플리케이션 코드를 작성하고, 이를 JAR 파일로 패키징합니다.

java -jar myapp.jar 명령어로 애플리케이션을 실행합니다.

 

결론

 

전통적인 스프링 애플리케이션: 주로 WAR 파일을 사용하여 웹 애플리케이션 서버에 배포.

스프링부트 애플리케이션: 주로 JAR 파일을 사용하여 독립 실행형 애플리케이션으로 배포.

반응형
반응형

 

웹사이트 접속:

JetBrains의 공식 웹사이트에 접속합니다. JetBrains 공식 웹사이트 링크를 클릭하거나 웹 브라우저에서 “IntelliJ IDEA download”로 검색하여 접근할 수 있습니다.

3. Community Edition 및 Ultimate 다운:

 두 버젼 차이 

Community Edition은 JVM 언어로 작업하는 개인 개발자나 학생들에게 적합한 반면, Ultimate Edition은 다양한 프로그래밍 언어와 웹 개발, 데이터베이스 관리, 서버 관리 등 복잡한 기업용 애플리케이션을 개발해야 하는 전문 개발자나 기업에 적합한 버전입니다. 이를 통해 개발 환경의 요구 사항과 예산에 맞는 적절한 버전을 선택할 수 있습니다.


2. 
운영 체제 선택:

 다운로드 페이지에서 사용 중인 운영 체제에 맞는 버전을 선택합니다. Windows, macOS, Linux 중에서 선택할 수 있습니다.

 

윈도우 

https://www.jetbrains.com/idea/download/?section=windows#section=windows

 

Download IntelliJ IDEA – The Leading Java and Kotlin IDE

Download the latest version of IntelliJ IDEA for Windows, macOS or Linux.

www.jetbrains.com

mac 

https://www.jetbrains.com/idea/download/?section=mac#section=mac

 

Download IntelliJ IDEA – The Leading Java and Kotlin IDE

Download the latest version of IntelliJ IDEA for Windows, macOS or Linux.

www.jetbrains.com

 

intelliJ IDEA에서 새 프로젝트 생성하기

 

1. IntelliJ IDEA 실행:

IntelliJ IDEA를 실행합니다. 이미 열린 프로젝트가 있다면, File 메뉴에서 Close Project를 선택하여 현재 프로젝트를 닫습니다.

2. 새 프로젝트 시작:

시작 화면에서 New Project를 선택하거나, File 메뉴에서 New -> Project...를 선택합니다.

3. 프로젝트 유형 선택:

왼쪽 패널에서 Java를 선택합니다. (IntelliJ IDEA Ultimate Edition을 사용하는 경우 다른 프로그래밍 언어나 프레임워크를 선택할 수 있습니다.)

프로젝트 SDK를 설정합니다. SDK가 설정되어 있지 않은 경우, Add SDK를 클릭하여 JDK를 설치하거나 기존에 설치된 JDK를 선택합니다.

 

5. 프로젝트 정보 입력:

Next 버튼을 클릭한 다음, 프로젝트의 이름과 저장 위치를 입력합니다.

Project name: 프로젝트의 이름을 입력합니다.

Project location: 프로젝트 파일을 저장할 위치를 지정합니다.

 

6. 프로젝트 생성 완료:

모든 설정을 마쳤다면 Finish 버튼을 클릭하여 새 프로젝트를 생성합니다.

IntelliJ IDEA가 새 프로젝트를 설정하고 초기화하는 과정을 진행합니다.

 

7. 프로젝트 구조 확인:

프로젝트가 생성된 후, 프로젝트 디렉토리 구조를 확인할 수 있습니다. 일반적으로 src 폴더가 생성되며, 여기에 소스 코드 파일을 추가할 수 있습니다.

 

이제 IntelliJ IDEA에서 새로운 프로젝트를 생성하고 기본 설정을 완료했습니다. 이 프로젝트를 기반으로 Java 코드를 작성하고 개발을 진행할 수 있습니다. 프로젝트 설정을 변경하거나 추가 구성이 필요한 경우, File 메뉴에서 Project Structure를 선택하여 다양한 프로젝트 설정을 조정할 수 있습니다.

 

우측 상단에 실행버튼으로 부트 로컬 실행

 

반응형
반응형

STS > File > New > Spring Starter Project
Intellij > File > new > project > Spring Initializr

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class SpringBootBoilerPlateApplication {
  public static void main(String[] args) {
    SpringApplication.run(SpringBootBoilerPlateApplication.class, args);
  }
}

maven으로 프로젝트 빌드

프로젝트 우클릭 > Run as > maven clean > maven install > maven build.. > Spring boot app 으로 프로젝트 시작

~

~

Application 클래스의 main 메소드가 시작된다.
이 때 해당 클래스 명이 아니더라도 @SpringBootApplication 어노테이션이 있는 클래스의 main 메소드가 실행됨

@SpringBootApplication

어노테이션은 이 3개의 어노테이션을 모두 담고 있는 어노테이션이다.

@SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan

스프링부트가 나오기 전까지는 ViewResolver를 설정하기 위해서 application-context.xml이 servlet-context.xml에
추가하거나, JavaConfig 기반의 환경일 경우, @Configuration 클래스 - WebMvcConfig등의 클래스 - 에 ViewResolver설정을 해줘야 했었다.

먼저 간단한 Controller 클래스를 만드는데, 클래스가 만들어지는 위치가 중요하다.
스프링부트는 메인클래스의 설정에 의해 컴포넌트스캔을 한다고 했었는데,
스프링부트는 컴포넌트 스캔을 할 때, 기본적으로 메인클래스가 있는 위치를 기준으로 스캔을 하게된다.

ComponentScan 

만약, AutoScan이 되어야 하는 컴포넌트 클래스들 - 대표적으로 @Controller, @Service, @Repository, @Component등-의 위치가 메인클래스가 위치한 패키지보다 상위 패키지에 있거나, 하위가 아닌 다른 패키지에 있는 경우, 스캔이 되지 않는다.

이런 문제를 해결하기 위해서는,
명시적으로 ComponentScan을 할 Base Package를 지정해주면 된다.

@EnableAutoConfiguration(exclude={DataSourceAutoConfiguration.class})
메인클래스에 Annotation을 추가함으로써 SpringBoot시작시 실행되는 Auto Configuration 작업중 DatatSource 설정부분을 제외시킬 수 있다.

@SpringBootApplication
@EnableAutoConfiguration(exclude={DataSourceAutoConfiguration.class})  // Datasource설정은 자동설정에서 제외
@ComponentScan(basePackages = "com.boilerPlate.app")

 

SpringBootApplication문서

 

반응형

+ Recent posts