▣ LAB · MVC

분업 vs 한 덩어리 비교

MVC — 왜 분업하나 / 약 15분

📍 지금 어디를 만지고 있나요?
브라우저
→
Spring MVC 6 계층
→
DB

사전 준비

이번 실습의 목표

「한 덩어리 코드」와 「분업된 코드」를 모두 짜보고, 왜 분업이 유연성을 만드는지 손으로 느낍니다.

1
한 덩어리 — 컨트롤러에 다 박기
@Controller
public class BadController {
    @RequestMapping("/bad")
    public String all(Model m) {
        // DB 직접 접근, 비즈니스 로직, 화면 데이터 가공
        // 모두 여기에...
        Connection c = ...;
        ResultSet rs = ...;
        // 길고 복잡
        m.addAttribute("data", processed);
        return "bad";
    }
}
CHECKPOINT
  • 이 컨트롤러는 변경 사유가 몇 가지인가요? (정답: SQL 변경, 로직 변경, 화면 변경 — 3 가지)
  • 테스트하기 어려운 이유는? (정답: DB 가 없으면 메서드 자체를 호출 못 함)
2
분업 — 3 계층으로 분리
@Repository  // DB 접근만
public interface DataMapper { List findAll(); }

@Service     // 비즈니스 로직만
public class DataService {
    @Autowired DataMapper mapper;
    public List getData() {
        return mapper.findAll().stream()
                .filter(i -> i.isValid())
                .toList();
    }
}

@Controller  // 요청 처리만
public class GoodController {
    @Autowired DataService service;
    @RequestMapping("/good")
    public String list(Model m) {
        m.addAttribute("data", service.getData());
        return "good";
    }
}
CHECKPOINT
  • 각 계층의 변경 사유가 하나씩으로 분리됐나요?
  • Service 만 단위 테스트 가능 (Mapper 를 Mock 으로)
3
변경 시뮬레이션 — 화면만 바꾸기

"기존 테이블을 카드 형태 UI 로 변경" 요청이 왔을 때:

CHECKPOINT
  • 「식당 인테리어가 바뀌어도 셰프는 안 바뀐다」가 코드에서 어떻게 나타나는지 확인

실습 완료 체크리스트

한 덩어리 코드의 변경 사유 3 가지를 식별
분업 코드로 다시 짜기
화면 변경 시 어디만 수정되는지 확인
분업의 유연성 효과를 입으로 설명할 수 있다
← 이전메인으로다음 →