打包 MVP 层有什么最佳实践吗？

Question

我已经使用 MVP 方法完成了一些 Android 应用程序，

但我不太确定将同一特征的不同层对象放在同一个包中是否更好？或者将不同功能的所有层项目打包在同一个包中，并在上面加上层名称？

（我的意思是这样的）

目前，我正在遵循第二条规则，但这是最佳做法吗？

编辑: 这是我项目的全部包！ :)

Answer 1

您应该为基本 MVP 类和每个 MVP 实体创建单独的包。例如，'mvp_base' 用于基本内容和 'some_screen' 包，在其中您将拥有 Activity、片段等。'some screen' 的具体 mvp 实现放入 'mvp' 包在 'some_screen' 包内。将所有模型和演示者存储在服务中并在 UI 创建时绑定到它也是一个好主意。

Answer 2

创建一个包含 Contract interface 的特定功能包，其中包含 View 和 Presenter 接口。该功能包还包含 View 和 Presenter 接口的实现（即 Activity 和 Presenter 类）。

我做了一个sample project here；您可以参考它以获取有关 MVP 的更多信息。

Answer 3

只是想把我的想法融入其中。我已经使用这些方法中的每一种来处理项目。我现在的偏好是按功能打包。我更喜欢这种方法有两个主要原因：

易于上手

提高了代码库新开发人员对项目结构的可见性。当与单个功能相关的类组合在一起时，新团队成员可以更轻松地快速了解所有内容是如何组合在一起的。

限制Class访问

这可能更重要。当您按类型打包时（所有 Presenter 一起等），您必须在这些类 public 访问中提供许多方法。这可能会导致这些功能在代码库的各个区域被不当使用。

如果您按功能打包，那么这些类都在同一个包中，因此您可以授予方法包级别的访问权限。这确保方法不会泄漏。

Answer 4

我更喜欢主包中的这种打包模式：

常见的 classes 发生在 main.
每个包都是应用程序的一个功能或应用程序的一层。
数据：数据层。包含用于数据的 classes。例如域 classes、存储库 classes、数据源 classes 等
如果您设计 Mvp - 清洁架构 并在 Interactor class 中开展业务。（或 Use-Case classes）你可以在相关功能中创建一个 domain 包并将它们放在这个位置。
Util 包含 util classes.
视图和演示者在名为 Contract 的 class 中定义。

这里有一个例子 Contract class:

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();
    }
}

根据我的说法，此模型的主要好处是看到包模型的人可以轻松理解应用程序的层、功能和要求。

打包 MVP 层有什么最佳实践吗？

Is there any best practice for packaging MVP layers?

java

mvp

android