用例2的方式进行相同的动作 [英] Use Case with 2 ways for the same action

问题描述

问1：什么是要建立一个用例2的方式做同样的动作的正确方法（或多个）

Question 1: What is the correct way to build a Use Case (or more than one) with 2 ways to do the same action?

例如：

我有一个iOS应用中3个屏幕：结果
1.地图视图，可以是长pressed，并有摄像头按钮。结果
2.摄像头视图中，如果用户点击地图视图相机按钮，如图。结果
3.地方/针编辑视图，如果用户长presses地图视图，或者选择在摄影机视图照片的用户后显示。该编辑观点有一个保存按钮实际创建（如果相机按钮是presses长preSS协调或当前位置）中的照片和位置的地方。

I have a 3 screens in an iOS app:
1. A map view, which can be "long pressed" and has a camera button.
2. A camera view, which is shown if the user taps the camera button in the map view.
3. A place/pin editing view, which is shown if the user "long presses" the map view, or after the user chooses a photo in the camera view. This editing view has a save button to actually create the place with a photo and the location (long press coordinate or current location in case the camera button was presses).

标题：创建地点
基本流程：结果
 1.用户长preSS在地图上。结果
 2.应用滴临时密码并显示就地编辑视图。结果
 3.用户编辑位置信息和presses保存按钮。结果
 4.应用程序创建的地方，保存它。结果

Title: Create Place Basic flow:
1. User "long press" on the map.
2. App drops a temporary pin and displays the place editing view.
3. User edits the place information and presses save button.
4. App creates the place and save it.

标题：创建地点
基本流程：结果
 1.用户presses加号按钮。结果
 2.应用程序显示摄影机视图。结果
 3.用户拍照。结果
 4.应用程序创建了当前的位置和图像的地方。结果

Title: Create Place Basic flow:
1. User presses plus button.
2. App displays camera view.
3. User takes a picture.
4. App creates place with current location and picture.

基于注释更新bhavik交换。

问题2：（适用于bhavik的回答基于）结果
所以，我并不需要一个交互件precisely 1 presenter，我可以有1相互作用分子和3 presenters /视图。

Question 2: (Based on bhavik's answer)
So I don't need one presenter for one interactor precisely, I can have 1 interactor and 3 presenters/views.

1. 在我的情况，我应该有一个presenter /供图，这是它开始，结果
视图

2. 那么我应该有一个presenter /相机视图，如果用户点击拍照按钮结果


3. 和一个presenter /视图编辑视图，万一用户长presses或用户后，从相机presenter /视图选择照片并重定向到相同的编辑视图。

这是否正确？

问题3：我应该为交互件边界方法总是返回void结果？
在bhavik的榜样，他们正在返回的东西，但在 VIPER博客并的叔叔Bob的影片他们总是返回void，结果进来另一个边界法的形式交互件呼吁在presenter /控制器。

Question 3: Should my boundary methods for the interactor always return void?
In bhavik's example they are returning something, but in the VIPER blog and the uncle Bob's video they always return void and the result comes in the form of another boundary method that the interactor calls on the presenter/controller.

问题4：的VIPER方式不使用控制器，只有presenter交谈的交互器，当叔叔Bob的视频使用一个控制器和不同的一个presenter与相互作用分子的相互作用。我应该采取哪种方法？

Question 4: The VIPER way does not use a controller, only a presenter to talk to the interactor, when the uncle Bob's video uses a controller and a presenter for different interactions with the interactor. Which approach should I take?

问题5：如果我用例是一样的东西去其他屏，它应该甚至有交互件？由于当前视图会告诉它的presenter是pressed什么按钮（去什么视图）和该电流presenter会告诉它的线框这个其他线框改变。

Question 5: If my Use Case is something like "Go to other screen", should it even have an interactor? Since the current view will tell its presenter what button was pressed (what view to go to) and this current presenter will tell its wireframe "change to this other wireframe".

推荐答案

问1：什么是有2种方式做同样建一个用例（或多个）的正确方法行动？

Question 1: What is the correct way to build a Use Case (or more than one) with 2 ways to do the same action?

在VIPER的设计，您可以创建在同一个交互器两种方法适合用例的每个主要和交替。

In VIPER design, you can create two methods in the same Interactor suitable for each primary and alternates of the use case.

问题2：（基于bhavik的答案）
所以，我并不需要一个交互件precisely 1 presenter，我可以有1相互作用分子和3 presenters /视图。

Question 2: (Based on bhavik's answer) So I don't need one presenter for one interactor precisely, I can have 1 interactor and 3 presenters/views.

，我想我更好地理解它。

Based on our discussion and your updates, I think I understand it better.

• presenter /视图不应该比交互器的更多互动。


• presenter /查看不得与任何交互器在所有的互动，在 CameraView 的情况。


• 他们是在奇才中间的看法。


• 多presenter /视图可以用单一交互器进行交互。


• 交互器不绑定到任何presenter。


• 单交互器负责一次性使用情况和它的所有备用流。 1-1的关系。

所以，你应该有一个 EditPlace presenter /查看为 EditPlaceInteractor 传递数据将数据与或无照片。

So, you should have single EditPlacePresenter/View for EditPlaceInteractor that pass data Place data with or without Photo.

问题3：我应该为交互件边界方法总是返回void

Question 3: Should my boundary methods for the interactor always return void?

在bhavik的榜样，他们正在返回的东西，但在VIPER博客和叔叔Bob的视频，他们总是返回void，结果进来另一个边界法的形式，在presenter /控制器上的交互器调用。

In bhavik's example they are returning something, but in the VIPER blog and the uncle Bob's video they always return void and the result comes in the form of another boundary method that the interactor calls on the presenter/controller.

我想你指的是从交互器接收到的结果低于presenter方法​​。

I think you are referring to the below Presenter method that receives results from the Interactor.

- (void)foundUpcomingItems:(NSArray*)upcomingItems

有关上述工作，交互器将具有将有线/通过由presenter /控制器寻找结果或数据修补委托实例。这意味着presenter /控制器绑定到交互器或他们的参考或返回函数指针，在每个交互器方法调用传递。是设计？

For the above to work, the Interactor will have delegate instances that will be wired/patched through by the Presenter/Controller looking for result or data. This means the Presenter/Controller is tied to Interactor or their reference or return-function-pointer is passed in each Interactor method call. Is that by design?

我想，交互器应该返回数据按照用例。例如交互器应与成功或失败返回EditPlaceResult。

I think, Interactor should return data as per the use case. For example Interactor should return the EditPlaceResult with success or failure.

• 如果成功，它应该包括保存的数据，例如将ID。


• 如果失败，应包括失败的原因。

这应该是用例的一部分。如果没有的话，它应该不会返回任何东西。它会返回void和一个独立的交互器将presenter进行查询，以检查是否成功或不添加地图地点。

This should be part of the use case. If not then, it should not return anything. It will return void and a separate Interactor will be queried by Presenter to check if Map Place was added successfully or not.

在博客中引用：

• presenter包含视图逻辑为preparing内容从交互器显示的作为接收


• 其高达presenter取数据的由交互器返回并格式化为presentation。


• 的presenter 接收结果从交互器，并将结果转换成一种形式，是有效的在视图中显示。

• Presenter contains view logic for preparing content for display as received from the Interactor.
• Its up to the Presenter to take the data returned by the Interactor and format it for presentation.
• The Presenter receives results from an Interactor and converts the results into a form that is efficient to display in a View.

问题4：的VIPER方式不使用控制器，只有presenter交谈的交互器，当叔叔Bob的视频使用一个控制器和不同的一个presenter与相互作用分子的相互作用。我应该采取哪种方法？

Question 4: The VIPER way does not use a controller, only a presenter to talk to the interactor, when the uncle Bob's video uses a controller and a presenter for different interactions with the interactor. Which approach should I take?

您需要定义以下导航VIPER路线：

You need to define VIPER routes for following navigation:

• 相机按钮：从导航图形页面到 CameraView （使用位置）


• 龙preSS：从导航图形页面到 EditPlaceView （使用坐标）

采取
• 照片：从 CameraView 导航到 EditPlaceView


• 保存地点：发送交互器保存有/无放置照片的请求的情况而定，并跳回图形页面如果成功


• 后退按钮：返回到previous查看基于导航堆栈

• Camera Button: Navigate from MapView to CameraView (Use Location)
• Long Press: Navigate from MapView to EditPlaceView (Use Coordinate)
• Photo taken: Navigate from CameraView to EditPlaceView
• Save Place: Send Interactor a request to Save Place with/without Photo as the case may be and jump back to MapView if successful
• Back Button: Back to previous View based on Navigation Stack

按毒蛇博客，视图控制器和导航控制器由presenters和线框使用。

As per the VIPER blog, view controllers and navigation controllers are used by Presenters and Wireframes.

VIPER线框处理导航，使视图控制器成为精干，意思是说，查看控制机器。

VIPER Wireframe handles Navigation and makes view controllers become lean, mean, view controlling machines.

基本上线框抽象了导航控制器，而是提供路由定义。

Basically Wireframe abstracts away navigation controller and instead provides route definition.

线框

• 旗下拥有的UINavigationController的UIViewController和


• 负责创建视图/的ViewController并在窗口安装它


• 路由在线框定义，包含导航逻辑用于描述屏幕的次序
显示

presenter

• 使用线框来进行导航


• 要保持视图控制器精简，VIPER需要给视图控制器的方式来告知有关各方，当用户采取某些行动 - ！presenters来到这里


• 基于这些动作的视图控制器不应该作出决定，但它应该通过这些事件一起的东西，可以 - ！presenters应该是决策

问题5：如果我用例是一样的东西去其他屏，它应该甚至有交互件？由于当前视图会告诉它的presenter是pressed什么按钮（去什么视图）和该电流presenter会告诉它的线框这个其他线框改变。

Question 5: If my Use Case is something like "Go to other screen", should it even have an interactor? Since the current view will tell its presenter what button was pressed (what view to go to) and this current presenter will tell its wireframe "change to this other wireframe".

没有。作为导航使用情况下，一部分可能不需要交互器。它是唯一的转换。目标presenter可能需要一个交互器。例如， CameraView / presenter 不需要交互器，但 EditPlaceView 需要保存的地方。

No. Navigation as part of use case may not need Interactor. It is transition only. The target Presenter may need an Interactor. For example, CameraView/Presenter does not need Interactor but EditPlaceView needs to save the place.

总评：
架构模式背后的思想是给定的软件应用程序分成互连部分，以便从该信息是presented或从用户接受的方式分开的信息的内部重新presentations。 MVC，MVP，MVVM，VIPER都集中在以某种方式或其他隔离观，逻辑和导航。

Overall: The idea behind architectural patterns is to divide a given software application into interconnected parts, so as to separate internal representations of information from the ways that information is presented to or accepted from the user. MVC, MVP, MVVM, VIPER all focus on isolating View, Logic and Navigation in one way or other.

架构模式在他们打算什么分解有限。我们必须明白，架构模式不分解或隔离的一切。此外，如果一个建筑图案代表一定的责任，以某一部分，其他没有做，在所有可能或分配多个职责单一的一部分。

Architectural patterns are limited in what they intend to decompose. We have to understand that architectural patterns do not decompose or isolate everything. Also if one architectural pattern delegates certain responsibilities to certain part, other does not do that at all probably or assign multiple responsibilities to single part.

我们被允许延长或限制的隔离和分解，它证明了原因，并不会强加的那超支成本的担忧不必要的分离程度。您可以选择使用的导航控制器和您的presenter可以对他们的依赖，而不定义线框路线。然后，这些控制器将负责屏幕之间的导航。

We are allowed to extend or limit the isolation and decomposition to the extent that it justifies the cause and does not impose unnecessary separation of concerns that overrun the cost. You can choose to use navigation controllers and your presenter can take dependency on them without Wireframe routes defined. These controllers then will be responsible for the navigation between screens.

这篇关于用例2的方式进行相同的动作的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！