MVC (Model-View-Controller) 구조

MVC (Model-View-Controller)

• 소프트웨어 디자인 패턴으로, 응용 프로그램을 세 가지 주요 구성 요소로 분리하여 효율적인 코드 관리와 유지보수를 가능하게 합니다.

 

1. Model: 데이터와 비즈니스 로직을 관리합니다.
2. View: 사용자에게 데이터를 표시하는 데 사용됩니다.
3. Controller: 사용자의 입력을 처리하고, 모델과 뷰를 업데이트합니다.

MVC 프로젝트 구조

src/main/java/com/example/demo/
├── controller
│   └── UserController.java
├── model
│   └── User.java
├── repository
│   └── UserRepository.java
├── service
│   └── UserService.java
└── DemoApplication.java

Entity

package com.example.demo.model;

import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;

@Entity
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String name;
    private String email;

    // getters and setters
}

 

Repository

package com.example.demo.repository;

import com.example.demo.model.User;
import org.springframework.data.jpa.repository.JpaRepository;
import org.springframework.stereotype.Repository;

@Repository
public interface UserRepository extends JpaRepository<User, Long> {
}

Service

package com.example.demo.service;

import com.example.demo.model.User;
import com.example.demo.repository.UserRepository;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

import java.util.List;
import java.util.Optional;

@Service
public class UserService {

    @Autowired
    private UserRepository userRepository;

    public List<User> getAllUsers() {
        return userRepository.findAll();
    }

    public Optional<User> getUserById(Long id) {
        return userRepository.findById(id);
    }

    public User createUser(User user) {
        return userRepository.save(user);
    }

    public void deleteUser(Long id) {
        userRepository.deleteById(id);
    }
}

Controller

package com.example.demo.controller;

import com.example.demo.model.User;
import com.example.demo.service.UserService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.*;

import java.util.List;
import java.util.Optional;

@RestController
@RequestMapping("/users")
public class UserController {

    @Autowired
    private UserService userService;

    @GetMapping
    public List<User> getAllUsers() {
        return userService.getAllUsers();
    }

    @GetMapping("/{id}")
    public Optional<User> getUserById(@PathVariable Long id) {
        return userService.getUserById(id);
    }

    @PostMapping
    public User createUser(@RequestBody User user) {
        return userService.createUser(user);
    }

    @DeleteMapping("/{id}")
    public void deleteUser(@PathVariable Long id) {
        userService.deleteUser(id);
    }
}

Application 

package com.example.demo;

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

@SpringBootApplication
public class DemoApplication {

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

application.properties

spring.datasource.url=jdbc:mysql://localhost:3306/yourdatabase?useSSL=false&serverTimezone=UTC
spring.datasource.username=yourusername
spring.datasource.password=yourpassword
spring.jpa.hibernate.ddl-auto=update
spring.jpa.show-sql=true
spring.jpa.properties.hibernate.format_sql=true
spring.jpa.database-platform=org.hibernate.dialect.MySQLDialect

 

• 이런 구조를 의미합니다
• 기본적인 CRUD(Create, Read, Update, Delete) 기능을 갖춘 간단한 사용자 관리 애플리케이션입니다.
• 실제 애플리케이션에서는 보안, 예외 처리, 유효성 검사 등의 추가적인 기능을 구현해야 합니다.

 

MVC 장단점

장점

1. 명확한 분리:
   • 유지보수 용이: 모델, 뷰, 컨트롤러가 각각 별도로 관리되므로 코드의 유지보수가 쉬워집니다. 한 부분을 수정해도 다른 부분에 영향을 미치지 않기 때문에 코드의 유연성이 높아집니다.
   • 협업 용이: 개발자들이 각각의 역할에 따라 나눠서 작업할 수 있습니다. 예를 들어, 백엔드 개발자는 모델과 컨트롤러를, 프론트엔드 개발자는 뷰를 개발할 수 있습니다.
2. 재사용성:
   • 모델 재사용: 동일한 모델을 여러 뷰와 컨트롤러에서 사용할 수 있습니다.
   • 뷰 재사용: 뷰는 데이터에 독립적이므로 다양한 데이터 소스와 함께 사용할 수 있습니다.
3. 테스트 용이:
   • 단위 테스트: 모델과 컨트롤러는 뷰와 독립적으로 테스트할 수 있으므로 단위 테스트를 수행하기가 더 쉽습니다.
   • 통합 테스트: 뷰와 컨트롤러 사이의 상호작용을 테스트하기 위한 통합 테스트도 용이합니다.
4. 유연한 변경:
   • UI 변경 용이: 뷰와 모델이 분리되어 있으므로 사용자 인터페이스를 변경해도 비즈니스 로직에 영향을 미치지 않습니다.
   • 비즈니스 로직 변경 용이: 모델의 비즈니스 로직을 변경해도 사용자 인터페이스에 영향을 미치지 않습니다.

단점

1. 초기 복잡도 증가:
   • 설계 및 설정: 초기 설계와 설정이 복잡할 수 있으며, 작은 프로젝트에서는 과도할 수 있습니다.
   • 학습 곡선: MVC 패턴을 처음 접하는 개발자들에게는 개념을 이해하고 구현하는 데 시간이 걸릴 수 있습니다.
2. 성능 저하 가능성:
   • 오버헤드: MVC 구조를 구현하는 데 필요한 추가적인 레이어로 인해 성능 오버헤드가 발생할 수 있습니다.
   • 동기화 문제: 모델과 뷰 사이의 데이터 동기화가 복잡해질 수 있으며, 잘못된 동기화로 인해 성능 저하가 발생할 수 있습니다.
3. 파일 및 클래스 증가:
   • 관리 복잡성: 프로젝트가 커질수록 파일과 클래스의 수가 증가하여 관리가 복잡해질 수 있습니다.
   • 디버깅 어려움: 여러 레이어로 분리되어 있으므로 디버깅 시 어떤 레이어에서 문제가 발생했는지 파악하기가 어려울 수 있습니다.
4. 개발 속도 저하:
   • 초기 개발 속도: 초기 단계에서는 구조 설정과 각 부분을 나누는 작업이 추가되어 개발 속도가 느려질 수 있습니다.