blocks|key|1400864|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|-4|4|5|6|B|7|@]|8|@]|9|$]]]|A|$]]

<blockquote>
&quot;If the call for the financial report comes from the web view then the
parameters received by the Financial Report Controller (for example
date) are probably in JSON format. If it comes from a print
instruction on a CLI application then it could be plain text.&quot;
</blockquote>
You don't pass in either of these to the interactor.
Note the <code>Financial Report Request</code> element; it has a <code>&lt;DS&gt;</code> tag on it; that's short for a data structure. It's either an actual data structure, or a just parameter list that a method on the <code>Financial Report Generator</code> has. The choice there is yours; creating an actual data structure creates better separation, is more explicit and more flexible, but it's also more work.
So, what you pass in is the data in the format specified by the request model. You don't pass in either of the source formats to the interactor, as these are external formats (unless you have purposefully adopted one of those formats as your request model, and accepted the tradeoffs that come with that). The controller module will convert the data to a <code>Financial Report Request</code> (it will either initialize the data structure, or if it's just parameters, it will just extract the values from the source data, and pas them as parameters), and then it will call a method on the interactor (<code>Financial Report Generator</code>) with that data.
<blockquote>
&quot;My second question is about the presenters. There is a Screen
Presenter and a Print Presenter. If the controller is called to get a
financial report, how does it know at the end which presenter to use
?&quot;
</blockquote>
This is an inheritance diagram; this is not depicting an instance of a <code>Screen Presenter</code> and an instance of a <code>Print Presenter</code> floating around. In the setup depicted, at runtime, there's just one or the other. The controller doesn't know which kind of presenter it's connected to, and it shouldn't - that's the whole point of dependency inversion. It only has a member variable that has the type of the <code>Financial Report Presenter</code> interface.
Some other code that knows about both (what's called the composition root, e.g., main, or a dependency injection container) will pick a concrete presenter and inject that instance in the controller. Then later on, when the controller has to use it, it will take the <code>Financial Report Response</code> returned by the interactor, and will use it to call some method (or maybe several methods) provided by the <code>Financial Report Presenter</code> interface; this will polymorphically invoke a method on the concrete presenter that has been &quot;plugged in&quot;.
Depending on how your application is structured, if the business logic of the interactor (report generator) doesn't require the same instance being shared, in your composition root, you might simply create one instance preconfigured to use the screen presenter to be used for screen-based tasks, and another instance preconfigured with a print presenter to be used for printing.
Or you might use the <a href="https://en.wikipedia.org/wiki/Composite_pattern" rel="nofollow noreferrer">Composite pattern</a> to combine several presenters into one (derive a <code>Composite Presenter</code> from the <code>Financial Report Presenter</code> interface, wrap several existing presenters). Your composite presenter could have some logic that allows it to switch to which of the child presenters it forwards to. Or, if you wanted to have the ability to output to all presenters simultaneously, you'd indiscriminately forward all the calls to all of the child presenters.
Or, a method on your controller could accept a derivative of the <code>Financial Report Presenter</code> interface as a parameter, so every time you call that method, you can pass in a different presenter.
The setup depicted is pretty flexible, but no design works well for every imaginable set of constraints, so depending on the details of the actual application and on it's change patterns, you might adjust some elements of the design.
<blockquote>
for example the company now wants to get financial reports in audio format so you can listen to it if you are blind or can't use a screen, how would you do it ? And what about controllers if the input is now in voice format too ?
</blockquote>
Well, I understand this is hypothetical, but, using voice recognition for input brings it's own set of problems beyond just having to deal with another format. However, suppose you already have a module (or even another application) that handles those problems for you - that module (or application) would ultimately output commands in a form of some data structure, that would then be converted to the <code>Financial Report Request</code>, which would then be passed to the report generator. On the other side of things, you'd have an <code>Audio Presenter</code> and an <code>Audio View</code> that would probably include a voice generator, that would accept it's own input (as plain text or some other format). This data would be generated based on the output of the interactor (the <code>Financial Report Response</code> data structure).
<blockquote>
&quot;If I have 10 types of reports, does that mean that the Screen
Presenter and Print Presenter have to implement 10 interfaces?&quot;
</blockquote>
I wouldn't do that, because that will likely lead to a big tangled mess of a class. Don't forget the single responsibility principle (SRP). (BTW, let go of the idea that you &quot;have to&quot; do things in a certain way - you (and your team) are the one(s) making design decisions, you can do whatever makes sense for your specific set of problems, nobody is going to grade you on this. Think of Clean Architecture as of a map, not a prescription.)
How you'd go about this completely depends on the details of your application &amp; business logic. E.g. if some of your reports use essentially the same data, but just show it in different ways (either visually, or maybe aggregate it along different axes, showing different types of summaries), you might opt to have a presenter for each kind of report, and have them all implement the same presenter interface. It's this interface that defines the input for the presenters, but note that, in this design, it's owned by the controller (the controller says &quot;I provide these kinds of outputs, and these are the output interfaces I support; if you want an output from me, implement the corresponding interface&quot;). So you might also choose to have a couple of controllers (e.g., if the way users interact with the system is sufficiently different in different scenarios). Or you might have methods on your controller that accept different kinds of top-level presenter interfaces as a parameter. Or a couple of controllers with such methods. Again, depends on the actual application, and on how far you want to go in adhering to separation of concerns.
You might be thinking that's too much work, but remember, these classes are supposed to be fairly small for the most part, and focused on a fairly narrow task. Another point, Clean Architecture is about structuring the dependencies; it doesn't really matter if all of its elements are represented by classes/objects - in principle, you can do it all with functions. Also, you don't have to get it all right at the very beginning, start with a best guess then evolve over time (that's why I said it's a map). See my answer <a href="https://softwareengineering.stackexchange.com/a/420360/275536">here</a> to see how you might arrive at a clean architecture–like dependency structure, starting from a typical function with an input and an output.
For reports that are fundamentally different, you might introduce a different presenter interface, and a different set of presenters. You'd also have to consider (or check by experimentation) how feasible your approach is - maybe one of the reports that's based on the same data takes too long to generate, but the others work fine, so you'd treat that one differently (adding a new presenter interface for it). You might also find that some reports involve barely any business logic, so you may decide to bypass the interactor completely and go directly to the database, where you'd rely on an SQL query to transform the data into the shape you need (note that this doesn't break the dependency rule).
Also, you don't have to follow the depicted design to a tee; in particular, if you have functionality that repeats over and over, you can extract/encapsulate it into a new class that you can then reuse. So feel free to introduce new elements into the design, or to split things, etc. (And in fact, there are probably elements that are omitted on the diagram you've posted.)
So, to find the answer, you have to think about what kinds or reports you are going to support, and what's the data you'll be working with, what modules you want to keep independent, etc. And you might not have all the information until the project has lived for some time; if you keep the project evolvable, you'll be able to reshape parts of the dependency structure as the need arises. Also note that not all parts of the codebase change at the same rate; those parts that barely ever change will derive little benefit from a full blown application of design principles; it's enough to keep them decoupled from parts that do change at the boundary where they interact.

I'm trying to understand how do controller and presenters work in clean architecture projects and could use some help. Specifically about generating multiple outputs from the use case.
In the Clean Architecture book there is an image that shows different outputs and a single controller for the same use case: Financial Report.
So my first question is how does the controller handle different inputs from the user ?. If the call for the financial report comes from the web view then the parameters received by the Financial Report Controller (for example date) are probably in JSON format. If it comes from a print instruction on a CLI application then it could be plain text. Do I need a controller for each use case ? Do I need a controller for each input type ?
<a href="https://i.stack.imgur.com/8ztmk.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/8ztmk.png" alt="enter image description here" /></a>
My second question is about the presenters. There is a Screen Presenter and a Print Presenter. If the controller is called to get a financial report, how does it know at the end which presenter to use ? The screen presenter would probably parse the Financial Report Response to html and the print presenter to a pdf file but how do we tell the controller (or the use case interactor) to call a specific presenter?
This is probably just an implementation detail and not really covered by the definition of clean architecture, but anyway, if you had to add a new presenter to this design, for example the company now wants to get financial reports in audio format so you can listen to it if you are blind or can't use a screen, how would you do it ? And what about controllers if the input is now in voice format too ?

Clean Architecture, how does the use case interactor generate different outputs?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我试图了解控制器和演示人员如何在干净的体系结构项目中工作，并可能需要一些帮助。特别是关于从用例中生成多个输出。在“清洁架构”一书中，有一个图像显示了相同用例的不同输出和一个控制器：Financial Report。因此，我的第一个问题是控制器如何处理来自用户的不同输入？如果对财务报告的调用来自web视图，那么财务报告控制器(例如日期)接收的参数可能是JSON格式的。如果它来自CLI应用程序上的打印

问清洁架构，用例交互器如何生成不同的输出？
EN

回答 1

Software Engineering用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问清洁架构，用例交互器如何生成不同的输出？EN