Android의 MVP 모델은 무엇인가요? 일반 쓰기 이벤트 처리 함수와 차이점은 무엇인가요?
MVP는 Android 뷰 객체를 보유하고 데이터를 처리하며 뷰를 새로 고치는 추가 프리젠터 클래스인가요?
일반적인 이벤트 처리 함수 작성과 다른 점은 이벤트 처리 함수의 코드를 프레젠터 클래스로 옮긴다는 점인가요?
그런데 이 정도 차이라면 별 것 아닌 것 같지만, 우리 모두 코드를 작성할 때 너무 추상적이지 않나요? 비즈니스 로직을 함께 추상화하면 왜 MVP의 개념을 분리해야 할까요?
typecho2017-06-17 09:18:12
개인적으로 장점은 다음과 같습니다.
1. 로직이 명확하고, 인터페이스가 View에 속하며, 데이터 처리가 Presenter에 속합니다. 코드를 읽는 것이 매우 어렵습니다. , 이후의 유지 관리 및 업그레이드도 어려울 것입니다. 남들이 작성한 코드를 보면 레이어링이 명확하지 않고 굉장히 어렵다는 점이 가장 두렵습니다.
2. 테스팅이 편리합니다. 테스팅을 위해 View에 바인딩할 필요가 없습니다.
给我你的怀抱2017-06-17 09:18:12
뷰를 처리하려면 프리젠터를 특별히 사용하라는 말씀이 맞습니다.
제가 생각하는 이점:
1. Presenter는 일반적으로 뷰의 인터페이스를 받습니다. 이러한 DIP(종속성 반전 원칙) 적용을 통해 가능한 한 추상화에 의존할 수 있으므로 구현하는 한 모든 뷰를 사용할 수 있습니다. 이러한 인터페이스는 이러한 처리 논리를 공유합니다.
2. SRP(단일 책임 원칙)를 적용하면 데이터 처리 논리 계층을 뷰에서 분리 및 분리할 수 있습니다
사실 우리의 개발은 약간 무작위적입니다. OCP 원칙에 따라 확장 개발 및 수정이 불가능합니다. 그러면 이때 코드를 수정하면 됩니다. 이전 코드를 다시 밀어넣거나 이전 코드를 기반으로 수정하는 것은 위험하고 비효율적인 동작입니다. MVP를 사용하는 경우 v2 또는 v3 버전이 있으면 몇 가지 컨트롤을 추가했을 수 있습니다. 컨트롤을 몇 가지 줄입니다. 이때 이전 코드를 직접 수정하면 MVP 프레임워크는 실제로 쓸모가 없지만 확장된 방식으로 개발하면 컨트롤이 더 많아집니다. 그런 다음 새 인터페이스를 작성합니다. 원래 뷰의 인터페이스를 상속한 다음 이전 뷰를 상속할 새 프리젠터를 만들고 그 안에 새 로직을 작성합니다. 이는 유지 관리 및 테스트에 편리하며 새 코드와 안정성만 테스트하면 됩니다. 프로그램은 성별을 향상시킬 수 있습니다.
따라서 MVP 모델에 따라 작성하면 자신도 모르게 코드의 유지 관리성이 더욱 강해집니다.
