[1차 세미나] 클래스간 역할 , 클래스 다이어그램

[jjuny-won]

클래스 간 역할

클래스의 역할

• Main : 클라이언트 역할, UI 제공해주는 역할
• Controller : Main 에서 받은 요청에 따라 필요한 로직을 호출해주는 역할로
• Service : Repository 와 Controller 사이 중개자 역할로 각 중간에서 데이터를 변환하거나, 저장할 객체를 생성한다
• Repository : 데이터를 저장하거나 , 저장된 데이터를 불러오는 역할

클래스 간 역할을 나누어 진행했을 때의 장점

(Model, View , Controller 로 분리했을 때의 장점)

• 사용자에게 보여주는 부분과 데이터를 처리하는 부분를 나누�어, 데이터를 체계적이고 안전하게 관리 할 수 있다.
• 입력 받은 데이터를 저장할 형식으로 맞추는 과정이 필요하기 때문이다. 클라이언트에서 받은 데이터를 바로 저장할 수 없다.
• 역할을 명확하게 나누어, 유지보수 가능하게 하고 쉽게 확장할 수 있다.

보충 (찾아본 부분)

MVC 패턴이란?

웹 애플리케이션에서 자주 사용하는 디자인 패턴으로 , Model, View, Controller 를 의미한다

• Model : 데이터 관리, 비즈니스 로직 처리하는 부분
• View : 사용자에게 제공하는 화면
• Controller : 사용자 요청이 들어오면 View와 상호작용해서 적절한 응답을 제공해주는 것

MVC 패턴을 지키려면!

1. 모델은 컨트롤러나 뷰에 의존하면 안된다.
   • 모델 내부에 컨트롤러 및 뷰와 관련된 코드가 있으면 안된다.
2. 뷰는 모델에만 의존해야 하고, 컨트롤러에는 의존하면 안된다.
   • 뷰 내부에 모델의 코드만 있을 수 있고, 컨트롤러의 코드가 있으면 안된다.
3. 뷰가 모델로부터 데이터를 받을 때는 사용자마다 다르게 보여주어야 하는 데이터에 한해서만 받아야 한다.
4. 컨트롤러는 모델과 뷰에 의존해도 된다.
   • 컨트롤러 내부에는 모델과 뷰의 코드가 있을 수 있다.
5. 뷰가 모델로부터 데이터를 받을 때는 반드시 컨트롤러에서 받아야 한다

MVC 의 한계점

• 하나의 Controller에 다수의 View와 Model이 복잡하게 연결되어 서로간의 의존성이 커지는 상황이 발생할 수 있다
• 컨트롤러의 역할이 과도하게 커진다면 Massive-View-Controller 현상을 피할 수 없다.
  • Massive-View-Controller
    • MVC 패턴에서 컨트롤러의 역할이 과도하게 커지고 복잡해지는 상황
    • Controller의 부담이 커졌으니 연관되어있는 Model과 View를 변경하는데도 굉장히 많은 비용이 발생할 수 있다
      → 해결 방안 으로 MVVM , MVP 패턴 등이 등장하게 됨

참고 : MVC , 한계점

클래스 다이어 그램 (진행중!)