TIL - 2025.03.12

[Yumi-Park996]

MVC 패턴

MVC(Model-View-Controller) 패턴은 소프트웨어 개발에서 애플리케이션을 모델(Model), 뷰(View), 컨트롤러(Controller) 세 가지 구성 요소로 분리하는 디자인 패턴입니다. 이를 통해 유지보수성, 확장성, 재사용성을 향상시키고, 개발 과정에서의 효율적인 역할 분담을 가능하게 합니다.

1. MVC의 배경

MVC 패턴은 1970년대 후반, Xerox PARC에서 Trygve Reenskaug에 의해 처음 제안되었습니다. 그는 복잡한 사용자 인터페이스를 체계적으로 관리하기 위한 방법으로 MVC를 고안하였으며, 이는 Smalltalk-80 프로그래밍 언어에서 처음 구현되었습니다.

2. MVC가 왜 필요한가

소프트웨어 개발에서는 사용자 인터페이스와 비즈니스 로직이 혼재되어 있을 경우, 코드의 복잡성이 증가하고 유지보수가 어려워집니다. MVC 패턴은 이러한 문제를 해결하기 위해 다음과 같은 이점을 제공합니다:

• 역할 분리: 각 구성 요소가 명확한 역할을 가지므로, 개발자 간의 작업 분담이 용이합니다.
• 유지보수성 향상: 한 구성 요소의 변경이 다른 부분에 미치는 영향을 최소화하여, 수정 및 기능 추가가 수월합니다.
• 재사용성 증가: 모델이나 뷰를 독립적으로 재사용하거나 교체할 수 있어, 개발 효율성을 높입니다.

이러한 이유로 MVC 패턴은 현대적인 소프트웨어 개발에서 널리 사용되고 있습니다.

3. MVC란 무엇인가

MVC 패턴은 다음과 같은 세 가지 구성 요소로 이루어집니다:

• 모델(Model): 애플리케이션의 데이터와 비즈니스 로직을 관리합니다. 데이터베이스와의 연동, 데이터 처리 등을 담당하며, 사용자에게 표시할 데이터를 제공합니다.

• 뷰(View): 사용자에게 데이터를 시각적으로 표현하는 부분입니다. 모델에서 받은 데이터를 기반으로 화면을 구성하며, 사용자 인터페이스 요소를 담당합니다.

• 컨트롤러(Controller): 사용자의 입력을 처리하고, 모델과 뷰 사이의 상호작용을 관리합니다. 사용자의 요청을 받아 적절한 모델을 호출하고, 그 결과를 뷰에 전달하여 화면에 반영되도록 합니다.

이러한 구성 요소 간의 상호작용을 통해 애플리케이션의 흐름이 제어됩니다.

4. MVC가 없다면 무엇이 불편한가

만약 MVC 패턴을 적용하지 않고, 사용자 인터페이스와 비즈니스 로직이 혼재된 구조로 개발한다면 다음과 같은 문제가 발생할 수 있습니다:

• 코드의 복잡성 증가: 각 기능이 서로 얽혀 있어 코드를 이해하고 수정하기 어려워집니다.

• 유지보수 어려움: 한 부분의 변경이 다른 부분에 예기치 않은 영향을 미칠 수 있어, 버그 발생 가능성이 높아집니다.

• 재사용성 저하: 특정 기능이나 모듈을 다른 프로젝트나 부분에서 재사용하기 어렵습니다.

따라서, MVC 패턴을 적용함으로써 이러한 문제를 방지하고, 효율적인 개발 환경을 구축할 수 있습니다.

5. MVC 사례

MVC 패턴은 다양한 웹 프레임워크에서 채택되어 사용되고 있습니다. 대표적인 예시는 다음과 같습니다:

• Java의 Spring Framework: Java 기반의 대표적인 웹 프레임워크로, MVC 패턴을 중심으로 설계되어 있습니다.

• Python의 Django: 파이썬 기반의 웹 프레임워크로, MTV(Model-Template-View) 패턴을 사용하지만, 본질적으로 MVC 패턴과 유사한 구조를 가지고 있습니다.

• Ruby on Rails: 루비 언어를 사용하는 웹 프레임워크로, MVC 패턴을 기반으로 개발되었습니다.

이러한 프레임워크들은 MVC 패턴을 통해 개발자들이 효율적으로 애플리케이션을 개발하고 유지보수할 수 있도록 지원합니다.

[Yumi-Park996]

Servlet-review 코드 분석

MVC(Model-View-Controller) 패턴은 소프트웨어 개발에서 애플리케이션을 모델(Model), 뷰(View), 컨트롤러(Controller) 세 가지 주요 구성 요소로 분리하는 설계 패턴입니다. 이러한 분리는 코드의 유지보수성과 확장성을 향상시키고, 개발 과정에서의 역할 분담을 명확하게 합니다.

주어진 코드는 MVC 패턴을 활용하여 웹 애플리케이션을 구성하고 있습니다. 각 구성 요소별로 역할과 구현 방식을 상세하게 살펴보겠습니다.

1. 컨트롤러(Controller)

컨트롤러는 사용자 입력을 처리하고, 모델과 뷰 사이의 상호작용을 관리합니다. 사용자의 요청을 받아 적절한 모델을 호출하고, 그 결과를 뷰에 전달하여 화면에 반영되도록 합니다.

1.1 RootController.java

package org.example.pilates_helper.controller;

import jakarta.servlet.ServletException;
import jakarta.servlet.annotation.WebServlet;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;
import java.io.IOException;

@WebServlet("/")
public class RootController extends Controller {
    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException, ServletException {
        view(req, resp, "index");
    }
}

설명:

• 클래스 정의: RootController는 Controller 클래스를 상속받아 구현되었습니다.

• @WebServlet("/"): 이 애너테이션은 이 서블릿이 루트 URL(/)에 매핑됨을 나타냅니다. 즉, 사용자가 웹사이트의 루트 경로에 접근하면 이 컨트롤러가 요청을 처리합니다.

• doGet 메서드: HTTP GET 요청을 처리하며, view 메서드를 호출하여 "index"라는 이름의 뷰를 렌더링합니다.

기대 역할:

루트 경로에 대한 GET 요청을 처리하고, "index.jsp" 뷰를 사용자에게 제공하는 역할을 합니다.

1.2 Controller.java

package org.example.pilates_helper.controller;

import jakarta.servlet.ServletException;
import jakarta.servlet.http.HttpServlet;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;
import java.io.IOException;

public abstract class Controller extends HttpServlet {
    protected void view(HttpServletRequest req, HttpServletResponse resp, String name) throws ServletException, IOException {
        req.getRequestDispatcher("/WEB-INF/views/%s.jsp".formatted(name)).forward(req, resp);
    }
}

설명:

• 클래스 정의: Controller는 추상 클래스이며, HttpServlet을 상속받습니다.

• view 메서드: 주어진 이름의 JSP 파일을 찾아 해당 요청과 응답 객체를 전달하여 클라이언트에게 렌더링합니다.

기대 역할:

다른 컨트롤러들이 상속받아 사용할 수 있는 공통 기능(뷰 렌더링)을 제공합니다.

2. 모델(Model)

모델은 애플리케이션의 데이터와 비즈니스 로직을 관리합니다. 데이터베이스와의 연동, 데이터 처리 등을 담당하며, 사용자에게 표시할 데이터를 제공합니다.

2.1 APIClientParam.java

package org.example.pilates_helper.model.dto;

public record APIClientParam(String url, String token, String method, String body, String[] headers) {
}

설명:

• 레코드 정의: Java의 record 키워드를 사용하여 불변 객체를 정의합니다.

• 필드: API 호출에 필요한 URL, 토큰, HTTP 메서드, 요청 본문, 헤더 등을 포함합니다.

기대 역할:

API 호출 시 필요한 매개변수를 하나의 객체로 캡슐화하여 관리합니다.

2.2 TogetherRepository.java

package org.example.pilates_helper.model.repository;

import org.example.pilates_helper.util.APIClient;

public class TogetherRepository implements APIClient {
}

설명:

• 클래스 정의: TogetherRepository는 APIClient 인터페이스를 구현합니다.

기대 역할:

API 호출 기능을 활용하여 데이터베이스와의 상호작용을 처리합니다.

3. 서비스(Service)

서비스 계층은 비즈니스 로직을 처리하며, 컨트롤러와 모델 사이의 중간 다리 역할을 합니다.

3.1 TogetherService.java

package org.example.pilates_helper.service;

public class TogetherService {
}

설명:

• 클래스 정의: 현재는 비어 있지만, 추후 비즈니스 로직을 구현할 예정입니다.

기대 역할:

비즈니스 로직을 처리하고, 컨트롤러에서 요청한 작업을 수행하며, 필요한 경우 모델과 상호작용합니다.

4. 유틸리티(Utility)

유틸리티 클래스는 애플리케이션 전반에서 사용되는 공통 기능을 제공합니다.

4.1 APIClient.java

package org.example.pilates_helper.util;

import io.github.cdimascio.dotenv.Dotenv;
import org.example.pilates_helper.model.dto.APIClientParam;
import java.io.IOException;
import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
import java.util.logging.Logger;

public interface APIClient {

    private Logger getLogger() {
        return Logger.getLogger(this.getClass().getName());
    }

    private void info(String message) {
        getLogger().info(message);
    }

    private void error(String message) {
        getLogger().severe(message);
    }

    default String callAPI(APIClientParam param) {
        try {
            HttpResponse<String> response = httpClient.send(buildRequest(param), HttpResponse.BodyHandlers.ofString());
            info("% 

[Yumi-Park996]

(이어서)

4.1 APIClient.java 코드 분석

📌 APIClient.java 구성 요소 및 역할 정리

1. 패키지 및 라이브러리

• 패키지 (package)

  • util 패키지에 위치 → 프로젝트 전반에서 공통적으로 사용할 유틸리티 클래스.

• 라이브러리 (import)

  • dotenv: 환경 변수에서 API 키, URL 등의 정보를 로드.
  • HttpClient, HttpRequest, HttpResponse: HTTP 요청을 처리하는 Java 11 기능.
  • Logger: API 요청 및 응답 상태를 로그로 남기기 위한 도구.

---

2. 인터페이스 (APIClient)

• 인터페이스 (interface)
  • API 요청을 처리하는 기능을 정의하는 공통 인터페이스.
  • 이를 구현하면 다양한 클래스에서 공통적인 API 호출 기능을 사용할 수 있음.

---

3. 로깅 (Logger)

• 로그 객체 (getLogger())

  • 현재 클래스 이름을 기반으로 로그를 생성.
  • API 요청 및 응답 결과를 기록하는 용도로 사용.

• 로그 출력 (info() / error())

  • info(): API 요청이 성공했을 때 응답 코드 등을 출력.
  • error(): API 요청이 실패했을 때 오류 메시지를 출력.

---

4. API 호출 (callAPI())

• API 요청을 실행하고 응답을 반환하는 기능.
• HTTP 요청을 HttpClient로 전송하고, 성공 여부를 로그로 기록.
• API 요청에 문제가 생기면 예외를 던지고(throw), 오류 로그를 남김.

---

5. HTTP 클라이언트 (HttpClient)

• 싱글톤 객체로 선언 (httpClient)
  • API 요청을 보낼 때 사용하는 Java 11의 HTTP 클라이언트.
  • 같은 인스턴스를 계속 재사용하여 불필요한 객체 생성을 방지.

---

6. 환경 변수 (Dotenv)

• API 키, URL 등의 설정을 .env 파일에서 가져오는 기능.
• .env 파일이 없더라도 오류가 발생하지 않도록 설정 (ignoreIfMissing()).

---

7. API 요청 생성 (buildRequest())

• API 요청을 만들고 설정하는 역할.
• 요청할 URL, HTTP 메서드(GET, POST 등), 요청 본문(body), 헤더(headers) 등을 동적으로 설정.
• 완성된 HTTP 요청 객체(HttpRequest)를 반환.

---

🔥 정리: APIClient.java가 하는 일

1. API 요청을 실행하고(callAPI()) 응답을 반환.
2. 환경 변수(dotenv)에서 API 관련 설정을 가져옴.
3. HTTP 요청 객체를 생성하고(buildRequest()) API 호출을 보냄.
4. 요청 성공/실패 여부를 Logger로 기록.
5. API 호출 기능을 다른 클래스에서도 쉽게 사용하도록 인터페이스로 제공.

이제 이해가 좀 더 쉬워졌을까? 더 궁금한 점 있으면 말해줘! 🚀🔥

[Yumi-Park996]

📌 MVC 패턴과 레이어드 아키텍처의 차이점

✔ 둘은 완전히 같은 개념은 아니지만, 일맥상통하는 부분이 있음
✔ MVC 패턴은 애플리케이션의 "역할"을 분리하는 방식
✔ 레이어드 아키텍처는 애플리케이션의 "구조"를 계층으로 나누는 방식

---

1️⃣ MVC 패턴이란? (이미 알고 있는 개념)

"웹 애플리케이션을 Model, View, Controller로 나누는 설계 방식"
역할별로 분리하여 유지보수성과 코드의 가독성을 높이는 목적으로 사용됨.

• Model → 데이터와 비즈니스 로직 처리
• View → 사용자에게 보여지는 화면 (HTML, JSP, React 등)
• Controller → 사용자의 요청을 받아 Model을 조작하고 View를 반환

---

2️⃣ 레이어드 아키텍처란?

"소프트웨어를 기능별로 계층화하여, 각 계층이 역할을 분리하도록 설계하는 구조"
MVC보다 더 넓은 개념으로, 애플리케이션 전체의 계층 구조를 정의하는 방식.

✅ 레이어드 아키텍처의 기본 계층

1. Presentation Layer (프레젠테이션 계층)

   • 사용자 인터페이스 (UI)를 담당 (HTML, JSP, React 등)
   • MVC의 View와 연결됨

2. Controller Layer (컨트롤러 계층)

   • 사용자의 요청을 처리하는 계층
   • MVC의 Controller와 동일

3. Service Layer (서비스 계층)

   • 비즈니스 로직을 처리하는 계층
   • MVC 패턴에서는 Model이 처리하던 역할 중 일부를 나눠가짐

4. Repository Layer (저장소 계층, 데이터 계층)

   • 데이터베이스와 직접 연결되는 계층
   • DAO (Data Access Object) 역할을 담당

5. Infrastructure Layer (인프라 계층, 선택적 계층)

   • 로깅, 보안, API 호출, 캐싱 등의 공통 기능 처리

---

3️⃣ 차이점과 공통점

비교 항목	MVC 패턴	레이어드 아키텍처
개념	역할을 분리하는 구조	계층화하여 모듈화하는 구조
목적	UI, 비즈니스 로직, 데이터 처리 분리	유지보수성과 확장성을 높이기 위해 계층을 나눔
적용 범위	주로 웹 애플리케이션 (프론트-백엔드 포함)	모든 종류의 애플리케이션에 적용 가능
구성 요소	Model, View, Controller	Presentation, Controller, Service, Repository, Infrastructure
연결 관계	Controller가 Model을 호출하고 View를 반환	계층별로 분리된 구조에서 필요한 계층만 호출

---

4️⃣ 둘의 관계

✔ MVC 패턴도 레이어드 아키텍처의 한 종류라고 볼 수 있음
✔ 하지만 레이어드 아키텍처는 더 넓은 개념이고, MVC는 그 안의 일부 패턴
✔ 레이어드 아키텍처를 기반으로 MVC 패턴을 적용하는 경우가 많음

---

결론

1. MVC 패턴은 애플리케이션의 역할을 분리하는 구조 (Controller, Model, View)
2. 레이어드 아키텍처는 애플리케이션을 계층화하여 구조적으로 설계하는 방식
3. 레이어드 아키텍처를 기반으로 MVC 패턴을 적용하는 경우가 많다
4. MVC 패턴이 있다고 해서 반드시 레이어드 아키텍처를 따르는 것은 아니다
5. 규모가 커질수록 레이어드 아키텍처가 필수적이 된다

---

✅ 언제 MVC만 사용하고, 언제 레이어드 아키텍처를 사용해야 할까?

상황	MVC 패턴만 사용	레이어드 아키텍처 사용
프로젝트 크기	작은 프로젝트 (기능 적음)	중대형 프로젝트 (비즈니스 로직 많음)
유지보수성	중요하지 않음	중요함 (확장 가능해야 함)
팀 규모	1~2명 개발	여러 명이 개발
DB 접근 방식	간단한 CRUD 수준	여러 데이터 연산 및 API 연동