我正在使用MVP构建一个Android应用程序，我有一个关于这种模式的问题。
假设我有一个用于创建新人的屏幕。此屏幕将显示一个用于插入姓名的EditText，另一个用于姓氏，一个ImageView显示所选照片图片等。 这将导致一个View接口，由Fragment实现。它将与一个Presenter接口协作，由另一个类实现。
好。
现在我有另一个功能：用于编辑现有人员的屏幕。 碰巧的是，此功能的View与创建新人员的相同。但是，Presenter是不同的。它将首先从数据库加载现有人员，以使用当前数据预填充视图，单击"保存"时对数据库的操作将是更新而不是插入。
所以，我认为这是 MVP 的一个例子，其中一个视图与演示器的不同实现一起工作以实现不同的用例。
您认为这是一个正确的假设，还是您认为不同的功能应该具有不同的
View和Presenter接口？另外，如果你有一个共同的
View和不同的Presenters，View的实现是通用的，还是会导致两个类实现相同的接口？在实践中，我看到两种选择。只有一个
Fragment实施View。根据用户是要创建新人员还是更新现有人员，片段应接收并使用不同的演示者。有两个
Fragment。每个人都会实例化一个不同的Presenter。使用组合或继承来避免在两个片段之间复制代码。
您认为在这些情况下该怎么做更好？
谢谢。
当您在 Android 上使用 MVP 模式创建类似 CRUD 的应用程序时，您会遇到这种情况。
您可以轻松地只使用单个视图，只要您在课堂上很好地记录了它为两个不同的演示者暗示了"视图"，那么它"就可以">
我个人建议创建 2 个视图，一个用于"创建"，一个用于"编辑"(它们可能是相同的(目前)，但将它们分开可以清楚地表明它们是不同的东西。
您可以轻松地看到将来(或此模式的另一个含义)的情况，其中"创建"和"编辑"视图实际上具有不同的 API。或者略有不同的视觉提示，例如一个按钮标记为"创建/添加"，另一个按钮标记为"更新"。
我个人会创建一个视图库/帮助程序类，两个视图都从中提取逻辑。这应该可以帮助您降低整体 LoC，即使您创建了 2 个"视图"类。这样做的好处是，您可以轻松更改其中一个"创建/编辑"视图，而不必担心影响另一个视图。(我倾向于认为 2 个视图文件在创建/编辑之间存在"轻微"差异时会更容易维护)