jiiim_ni

Bean스프링 IoC 컨테이너가 관리하는 객체를 의미Spring 컨테이너에 의해 생성, 관리, 소멸됨애플리케이션 전역에서 재사용 가능기본적으로 싱글톤 스코프로 관리싱글톤싱글톤(Singleton)은 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴애플리케이션 전체에서 해당 클래스의 객체를 하나만 만들고, 그것을 공유해서 사용함싱글톤을 왜 사용할까?메모리 효율성: 최초 한 번만 객체를 생성하므로 메모리 낭비를 방지할 수 있습니다.데이터 공유와 일관성: 시스템 전반의 설정 정보나 공통 자원을 관리할 때 데이터의 일관성을 유지하기 쉽습니다.스프링 IoC ContainerBean의 생성 및 생명주기 관리의존성 주입 (DI)Bean 설정 정보 관리Bean 간의 의존 관계 설정Spring에서 IoC/..

3 Layer Architecture3 Layer Architecture는 소프트웨어 시스템을 세 개의 논리적 계층으로 분리하는 아키텍처3개의 레이어로 분리Controller Layer (Persentation Layer라고도 함)Service Layer (Business Layer, Application Layer라고도 함)Repository Layer (Data Layer라고도 함)3 Layer Architecture의 목적관심사의 분리각 계층은 고유한 책임만 담당변경 사항의 영향 범위 최소화유지보수성 향상코드의 가독성과 이해도 증가독립적인 테스트 가능재사용성 증대각 계층을 독립적으로 재사용모듈화된 설계확장성 개선특정 계층만 변경하여 기능 확장새로운 기술 도입 용이Controller Layer일반 사..

JDBC란?JDBC 자바 프로그램에서 데이터베이스에 접속하고 SQL 문을 실행하기 위한 도구JDBC로 할 경우)// JDBCpublic class UserDaoJdbc { public User findByName(String name) { Connection conn = null; PreparedStatement pstmt = null; ResultSet rs = null; User user = null; try { conn = DriverManager.getConnection( "jdbc:mysql://localhost:3306/hello", "user", "password"); ..

ERD(Entity Relationship Diagram)ERD는 데이터베이스의 구조를 시각적으로 표현하는 도구쉽게 말하자면, 테이블 구조를 그림으로 보여주는 설계도ERD의 필요성데이터베이스 구조를 한 눈에 파악할 수 있다.설계를 진행하며 논리적인 오류를 미리 발견하고 수정할 수 있다.데이터 구조를 문서화하여 다른 사람과의 소통을 원활하게 한다. (협업 관점)데이터 구조의 근본적인 결함을 제거하여 기술적 부채를 사전에 방지한다.Java 코드와 ERDORMORM이란?Object-Relational Mapping의 약자객체지향 프로그래밍 언어와 관계형 데이터베이스 간의 데이터 변환 기법프로그래밍 언어의 객체와 관계형 데이터베이스의 테이블을 자동으로 매핑하는 기술ORM의 핵심데이터베이스 종류에 관계없이 일관된..

데이터베이스데이터베이스(Database)란?여러 사람이 공유하고 사용할 목적으로 한 곳에서 관리되는 데이터의 조직화된 집합으로, 데이터를 소프트웨어에서 효율적으로 관리하기 위한 저장소-> 데이터의 집합 저장소데이터베이스의 종류관계형 DB(RDBMS)가장 많이 사용하는 데이터베이스데이터를 테이블 형태로 구조화하여 저장하고 관리하는 시스템테이블 간의 관계를 이용해 데이터를 연결ex) Oracle, MySQL, PostgreSQL, Microsoft SQL Server 등비관계형 DB (NoSQL)테이블이 아닌 key-value, document, graph 등의 다양한 형태로 데이터를 저장하고 관리스키마가 고정되지 않고, 대규모 데이터 처리와 높은 확장성을 제공ex) MongoDB, Cassandra, Re..

Controller와 RestController백엔드와 프론트엔드의 역할이 분리됨에 따라, 프론트엔드는 화면에 그려낼 Data가 필요백엔드는 주로 이 Data를 JSON 형식으로 내려줌1. @Controller전통적인 Spring MVC의 컨트롤러인 @Controller는 주로 View를 반환하기 위해 사용2. @RestController@RestController는 @Controller에 @ResponseBody가 추가된 것@ResponseBody란?@ResponseBody는 Spring MVC 컨트롤러의 메서드에 사용되는 어노테이션이 어노테이션이 붙은 메서드가 반환하는 값은 View를 찾는 데 사용되지 않고, HTTP 응답 본문(Response Body)에 직접 작성됨즉, JSON 형식으로 리턴하기 ..

ViewResolverViewResolver는 컨트롤러가 반환한 논리적인 뷰 이름을 실제 뷰로 바꿔주는 번역기 역할을 함@Controllerpublic class HelloController { @GetMapping("/hello") public String hello(Model model) { model.addAttribute("message", "Hello, Spring!"); return "hello"; // view }}위 코드에서 return "hello"; 코드는 ViewResolver에 의해 ”/templates/hello.html”이라는 실제 뷰 파일 경로와 매핑됨여기서 “hello”는 논리적인 뷰 이름이 되는 것이며, “/templates..

프론트 컨트롤러 패턴(Front Controller Pattern)프론트 컨트롤러 패턴이란?모든 클라이언트 요청을 단일 진입점(Single Point of Entry)에서 처리하는 디자인 패턴요청에 대한 공통 처리(보안, 로깅, 인코딩 등)를 중앙에서 효율적으로 관리할 수 있으며, 개별 요청을 처리할 핸들러(Controller)로 작업을 위임하는 역할을 함프론트 컨트롤러가 왜 필요할까?전통적인 방식의 문제점각 서블릿마다 공통 로직(인증, 로깅, 인코딩 등)이 중복됨새로운 기능 추가 시 모든 서블릿 수정 필요관리가 어렵고 일관성 유지 어려움프론트 컨트롤러 패턴을 사용한다면모든 요청을 하나의 컨트롤러가 받아서 처리(공통 로직을 중앙화)요청에 따라 적절한 컨트롤러로 위임프론트 컨트롤러 패턴의 장점공통 로직의 ..

서블릿의 문제점낮은 응집도 (Low Cohesion)하나의 서블릿 클래스 내에 HTTP 요청 처리, 비즈니스 로직, 데이터 접근, 응답 생성 로직이 모두 혼재함. 이는 단일 클래스가 너무 많은 책임을 갖게 하여 코드의 이해와 테스트를 어렵게 만든다.강한 결합도 (High Coupling)비즈니스 로직이 HttpServletRequest, HttpServletResponse와 같은 서블릿 API에 직접적으로 의존. 이로 인해 웹 환경 밖에서 단위 테스트를 수행하기가 매우 까다로워짐반복적인 상용구 코드 (Boilerplate Code)요청 파라미터 파싱, 타입 변환, 응답 컨텐츠 타입 설정 등 모든 요청에 대해 반복적인 코드가 필수적으로 요구됨이러한 문제들을 해결하기 위해 관심사의 분리(Seperation ..

Annotation어노테이션은 자바 코드에 메타 데이터를 추가하여 코드에 특별한 의미를 부여하거나, 컴파일러와 런타임에 특정 동작을 트리거하기 위해 사용됨대표적인 Annotation 예시: @Overridepublic interface Mouse { void leftClick(); void rightClick(); void scrollWheel();}public class LogitechMouse implements Mouse { @Override public void leftClick() { // 로지텍 좌클릭 로직 구현 } @Override public void rightClick() { // 로지텍 우클릭 로직 구현 } ..