개인적으로 장점은 다음과 같습니다.
1. 로직이 명확하고, 인터페이스가 View에 속하며, 데이터 처리가 Presenter에 속합니다. 코드를 읽는 것이 매우 어렵습니다. , 이후의 유지 관리 및 업그레이드도 어려울 것입니다. 남들이 작성한 코드를 보면 레이어링이 명확하지 않고 굉장히 어렵다는 점이 가장 두렵습니다.
2. 테스팅이 편리합니다. 테스팅을 위해 View에 바인딩할 필요가 없습니다.

뷰를 처리하려면 프리젠터를 특별히 사용하라는 말씀이 맞습니다.
제가 생각하는 이점:
1. Presenter는 일반적으로 뷰의 인터페이스를 받습니다. 이러한 DIP(종속성 반전 원칙) 적용을 통해 가능한 한 추상화에 의존할 수 있으므로 구현하는 한 모든 뷰를 사용할 수 있습니다. 이러한 인터페이스는 이러한 처리 논리를 공유합니다.
2. SRP(단일 책임 원칙)를 적용하면 데이터 처리 논리 계층을 뷰에서 분리 및 분리할 수 있습니다

사실 우리의 개발은 약간 무작위적입니다. OCP 원칙에 따라 확장 개발 및 수정이 불가능합니다. 그러면 이때 코드를 수정하면 됩니다. 이전 코드를 다시 밀어넣거나 이전 코드를 기반으로 수정하는 것은 위험하고 비효율적인 동작입니다. MVP를 사용하는 경우 v2 또는 v3 버전이 있으면 몇 가지 컨트롤을 추가했을 수 있습니다. 컨트롤을 몇 가지 줄입니다. 이때 이전 코드를 직접 수정하면 MVP 프레임워크는 실제로 쓸모가 없지만 확장된 방식으로 개발하면 컨트롤이 더 많아집니다. 그런 다음 새 인터페이스를 작성합니다. 원래 뷰의 인터페이스를 상속한 다음 이전 뷰를 상속할 새 프리젠터를 만들고 그 안에 새 로직을 작성합니다. 이는 유지 관리 및 테스트에 편리하며 새 코드와 안정성만 테스트하면 됩니다. 프로그램은 성별을 향상시킬 수 있습니다.
따라서 MVP 모델에 따라 작성하면 자신도 모르게 코드의 유지 관리성이 더욱 강해집니다.