MVC 아키텍처에서 왜 기능의 흐름이 아니라 같은 것끼리 묶어두는거임?

[익명(180.65)]

한 패키지 내에 하나의 데이터를 저장하고 꺼내오는 기능을 쭉 클래스형태로 만드는 것과

여러 패키지에 컨트롤러 기능을 하는거 따로 서비스 따로 DAO 따로 모아두는 것은 어떤 차이가 있는거임?

어차피 나중에 구분할때 기능별로 묶어서 보는거 아님? 규모가 엄청 커지게 되면 전자가 안 좋아지는거면

어떻게 안 좋아지는지 궁금함

[익명(8.37)]

그건 하기나름임 기능별로 모아도됨 - dc App

[익명(180.65)]

그런 식으로 진행하는 회사나 프로젝트도 있음? 결국엔 컨벤션을 따라야 되는건데 어떻게 짜는게 맞는건지 감이 안 잡혀서

[익명(ehbmnmedgtrdsvnh)]

마 직접 짜봐라 코딩이 훨씬 쉬워짐

[익명(180.65)]

아직 공부 중이라 잘 감이 안 잡혀서 그럼 어차피 중요한건 DB까지 퍼내리고 퍼올리는 과정이고 이건 일련의 정해진 과정이고 다른 기능들이 붙더라도 완전히 다른 두개가 들러붙는 수준은 아니지않아? 어떤 장점이 있는건지 헛갈려 감이 안 잡힘

[익명(ehbmnmedgtrdsvnh)]

새로운 기능을 추가해야 할때 어디서부터 시작해야할지 clear하

[익명(117.111)]

아키텍쳐는 방법론이지 절대 따라야할 규칙은 아님 다만 mvc 에장점은 패키지로 로직을 분리하면 유지보수가 쉬워지고 레이어 별로 데이터흐름을 제어하기 쉬움

[익명(210.90)]

MVC, MVP, MVVM 등 대표적인 디자인패턴 다시 공부해보셈. 그리고 답이 꼭 정해져있는건 아님. 먼저 코드 짜기 전에 프로젝트 설계 단계에서 프로젝트 크기, 유지보수 전부 고려해서 골라서 맞게 쓰는거지. 디자인 패턴도 어느정도 정규화 된 약속일 뿐임.

[익명(180.65)]

고마워 MVC만 들어봤지 그 뒤에 두개는 들어본 적도 없네 지식이 깊어졌다

[익명(1.239)]

Ddd 해라