MVC 패턴은 잘 정리된 블로그나 영상들이 너무 많다. 그래서 미션을 진행하면서 놓쳤던 부분들만 간단하게 정리를 한다.
private Cars enrollCars() {
String[] carNames = InputView.requestCarNames().split(",");
...
InputView에서 차 이름들을 반환할 때 split을 해서 List<String>을 넘겨줘도 괜찮아보여요.
네! 이 부분에 대해 그렇지 않아도 고민을 해봤는데요 세 가지 옵션이 있더라고요.
- scanner.readLine() 그대로 넘겨준다.
- 최소한의 가공을 해서 넘겨준다 (정수 데이터면 Integer.parseInt(), 여기서는 split()과 같은)
- 가공을 해서 객체를 생성해서 컨트롤러에게 넘겨준다 ( List 생성, PlayTime 생성 등)
이 스레드에서 같은 주제로 얘기가 나왔는데요, 저는 객체 생성을 해서 주는 것도 괜찮을 것 같다는 생각을 했거든요. 만약 도메인 규칙에 맞지 않다면 컨트롤러 단까지 오지 않고 바로 예외처리를 해줄 수 있으니까요.
어디까지가 적절한 범위일까요?
이 주제는 비슷하게 고민을 하고 있는 크루들도 꽤 있었다. 다만 1번과 2번에 많이 집중이 되어있었다.
좋은 질문입니다. 여기서도 MVC 패턴 얘기가 나올 수 있겠네요. Model과 View는 서로를 몰라야합니다. 객체를 생성해서 넘기는 건 해당 규칙을 위반한거겠죠.
지금도 View에서 Car를 알고있지 않냐고 반문하실 수 있을 거 같아요. 여기서 앞으로 많이 얘기를 듣게 될 dto 개념이 나옵니다. Car가 객체라면 CarDto는 그냥 View를 위한 데이터 덩어리입니다. 조금더 원론적으로 규칙을 적용하자면 dto를 만들어서 주고받을 수는 있겠네요(말은 이렇게 했지만 dto를 만들라는 코멘트는 아닙니다. dto라는 개념이 왜 필요한지 어렴풋이 느끼기만 하면 충분할 거 같아요).만약 도메인 규칙에 맞지 않다면 컨트롤러 단까지 오지 않고 바로 예외처리를 해줄 수 있으니까요.
이 얘기는 View가 도메인 규칙을 알고 있다는 거겠죠? 역시나 MVC 패턴을 잘 생각해보시면 도메인 규칙은 도메인에서 해결하는 게 제일 좋을 것 같아요.
이제 List<Integer>로 넘어가볼까요? 정수들의 리스트라는 건 도메인에 속할까요?
제 생각엔 이는 단순히 데이터의 형식만을 지정합니다. Input에서 데이터의 형식 정도를 안다고 도메인을 안다고 할 순 없겠죠. 오히려 어떤 형식으로 입력받을지 아는 건 View의 책임이라는 생각이 드네요.정리를 하자면
View에서는 지정된 형식의 데이터를 사용한다.
Controller는 View와 Model을 이어준다. View에서 지정된 데이터 형식을 주고받고, 이를 도메인 객체로 생성하고 도메인 객체에서 연산된 결과를 View로 넘길 수 있다.
정도가 될 거 같아요.
내가 빠트린 부분은 Model과 View가 서로를 몰라야한다는 점이다. 만약 MVC 패턴에서 서로의 경계가 뚜렷하지 않고 침범한다면 그것은 Model, View, Controller로 구분짓는 이유가 없을 것이다.