Есть ли какая-либо передовая практика для упаковки слоев MVP?

Я сделал некоторые приложения для Android, используя методологию MVP,

Но я не уверен, что лучше разместить объекты разных объектов одной и той же функции в одном пакете? или упаковать все слои элементов разных функций в одном пакете с именем слоя на нем?

(Что я имею в виду что-то вроде этого)

Скриншот пакетов

В настоящее время я следую второму правилу, но является ли это лучшей практикой?

Изменить : это все пакеты моего проекта! :)

Пакеты большего скриншота

java,android,mvp,

7

Ответов: 4


6 ">голосов принято

Просто бросить мои мысли в микс. Я работал над проектами с каждым из этих подходов. Теперь я предпочитаю пакет по функциям. Есть две основные причины, по которым я предпочитаю такой подход:

Простота индукции

Повышенная наглядность структуры проекта для разработчиков, новых для кодовой базы. Когда классы, относящиеся к одной функции, сгруппированы вместе, новому члену команды намного легче узнать, как все сочетается.

Ограничение доступа класса

Это, вероятно, более важно. Когда вы упаковываете по типу (все публики вместе и т. Д.), Вы должны предоставить много методов Contractдоступа к этим классам . Это может привести к ненадлежащему использованию этих функций из различных областей кодовой базы.

Если вы пакет по функции, то эти классы находятся в одном пакете, и поэтому вы можете предоставить доступ к уровню пакета методов. Это гарантирует, что методы не протекают.


2 ">

Создайте специальный пакет, содержащий interface Viewсодержащиеся в нем Presenterи Viewинтерфейсы. Пакет функций также содержит реализации интерфейсов Presenterи Activityинтерфейсов (т.е. классов Presenterи Presenterклассов).

Здесь я сделал образец проекта ; вы можете обратиться к нему за дополнительной информацией о MVP.


1

Вы должны создать отдельный пакет для базовых классов и пакетов MVP для каждого объекта MVP. Скажем, «mvp_base» для базового материала и пакета «some_screen», внутри которого вы будете иметь свою активность, фрагменты и т. Д. Конкретная реализация mvp для «некоторого экрана» помещена в пакет «mvp» внутри пакета «some_screen». Также рекомендуется хранить все ваши модели и презентацию внутри Сервиса и связываться с ним при создании пользовательского интерфейса.


1

Я предпочитаю эту модель упаковки в основном пакете:

введите описание изображения здесь

  • Общие классы проходят в основном.

  • Каждый пакет является функцией приложения или уровня приложения.

  • Данные: уровень данных. Содержит классы, которые используются для данных. Например, классы Interactor, классы репозитория, классы источников данных и т. Д.

  • Если вы проектируете архитектуру Mvp-Clean и выполняете свою деятельность в Use-Caseклассах. (или domainклассы) вы можете создать domainпакет в связанной функции и поместить их в это место.

  • Util содержит классы использования.

  • Просмотр и презентаторы определяются в названном классе Contract.

Вот пример Contractкласса:

interface SupportContract {
    interface View extends BaseView {
        void showTenthChar(char c);

        void showEveryTenthChar(@NonNull char[] chars);

        void showEveryWordWithCount(@NonNull HashMap<String, Integer> data);
    }

    interface Presenter extends BasePresenter<View> {
        void onSupportDataRequested();
    }
}

По моему мнению, основным преимуществом этой модели является то, что когда модель пакета может легко понять слои, особенности и требования приложения.

Java, Android, MVP,