8

我正在使用 MVP 构建一个 Android 应用程序，我对这种模式有一个疑问。

假设我有一个用于创建新人的屏幕。此屏幕将显示一个EditText用于插入姓名、另一个用于姓氏、一个ImageView用于显示选择的照片图片等。这将导致一个View界面，由Fragment. 它将与一个Presenter接口合作，由另一个类实现。

美好的。

现在我有了另一个功能：用于编辑现有人员的屏幕。碰巧的是View，此功能与创建新人的功能相同。但是，Presenter情况不同。它将首先从数据库加载现有人员以使用当前数据预填充视图，并且单击“保存”时对数据库的操作将是更新而不是插入。

所以，我认为这是 MVP 的一个例子，其中一个 View 与 Presenter 的不同实现一起工作以实现不同的用例。

  1. 你认为这是一个正确的假设，还是你认为不同的特性应该有不同的View和Presenter接口？

  2. 另外，如果您使用 commonView和 different Presenters，那么实现View是通用的，还是会导致两个类实现相同的接口？在实践中，我看到了两种选择。

    • 只有一个Fragment实现View. 根据用户是要创建新人还是更新现有人，Fragment 应该接收并使用不同的 Presenter。

    • 有两个Fragments。每一个都会实例化一个不同的Presenter. 使用组合或继承来避免两个片段之间的代码复制。

在这些情况下，您认为怎样做比较好？

谢谢。

4

1 回答 1

1

当您在 Android 上使用 MVP 模式创建类似 CRUD 的应用程序时，您会遇到这种情况。

你可以很容易地只拥有一个视图，只要你在课堂上很好地记录它为两个不同的演示者实现“视图”，那么它“没问题”

我个人建议创建 2 个视图，一个用于“创建”，一个用于“编辑”（它们可能是相同的（现在），但将它们分开可以清楚地表明它们是不同的东西。）

您可以很容易地看到未来的情况（或此模式的另一个实现），您的“创建”和“编辑”视图实际上具有不同的 API。或者略有不同的视觉提示，例如一个按钮标记为“创建/添加”，另一个按钮标记为“更新”。

我会亲自制作一个视图库/帮助器类，两个视图都从中提取逻辑。这应该可以帮助您减少整体 LoC，即使您制作了 2 个“视图”类。这样做的好处是您可以轻松更改“创建/编辑”视图，而不必担心影响另一个。（我倾向于认为，当创建/编辑之间甚至存在“轻微”差异时，这两个视图文件会更容易维护）

于 2015-12-20T06:26:39.723 回答