In his book 'Clean Architecture', Uncle Bob says that the Presenter should put the data that it receives into something he calls the 'View Model'.

enter image description here

Is this the same thing as the 'ViewModel' from the Model-View-ViewModel (MVVM) design pattern or is it a simple Data Transfer Object (DTO)?

If it is not a simple DTO, how does it relate to the View? Does the view get updates from it through an Observer relationship?

My guess is that it is more like the ViewModel from MVVM, because in Chapter 23 of his book, Robert Martin says:

[The Presenter's] job is to accept data from the application and format it for presentation so that the View can simply move it to the screen. For example, if the application wants a date displayed in a field, it will hand the Presenter a Date object. The Presenter will then format that data into an appropriate string and place it in a simple data structure called the View model, where the View can find it.

This implies that the View is somehow connected to the ViewModel, as opposed to simply recieving it as a function argument for example (as would be the case with a DTO).

Another reason why I think this is because if you look at the image, the Presenter uses the View Model, but not the View. Whereas the Presenter uses both the Output Boundary and the Output Data DTO.

If it is neither a DTO nor the ViewModel from MVVM, please elaborate as to what it is.

  • I think the answer is "it depends." If it's a web application then a view model is basically a DTO because it ultimately gets serialized as an HTML string. Otherwise a view model is just a specialized object for displaying the data to the view. – Greg Burghardt Oct 18 at 23:15
  • In MVVM(WPF, Winforms applications) ViewModel is wrapper for Controller, Presenter and ViewModel in Uncle Bob's Clean architecture. – Fabio Oct 18 at 23:19
  • @Greg Burghardt - When the ViewModel is a specialized data structure, how is the View notified of changes? – Fearnbuster Oct 19 at 0:09
  • @Fabio - If I take your meaning correctly your saying that in the MVVM pattern, the ViewModel is equivalent to all the components that are within the left most group of the diagram? If that is true for Uncle Bob's architecture, then why does he list the Controller and the Presenter separately? – Fearnbuster Oct 19 at 0:14
  • I think he separated input and output handlers to different objects/classes. In MVVM it could be Controller -> ICommand and Presenter -> data-binding mechanism. – Fabio Oct 19 at 1:24
up vote 14 down vote accepted

Is this the same thing as the 'ViewModel' from the Model-View-ViewModel (MVVM) design pattern

Nope.

That would be this:

enter image description here

That has cycles. Uncle Bob has been carefully avoiding cycles.

Instead you have this:

enter image description here

Which certainly doesn't have cycles. But its leaving you wondering how the view knows about an update. We'll get to that in a moment.

or is it a simple Data Transfer Object (DTO)?

To quote Bob from the previous page:

You can use basic structs or simple data transfer objects if you like. Or you can pack it into a hashmap, or construct it into an object.

Clean Architecture p207

So, sure, if you like.

But I strongly suspect what's really bugging you is this:

enter image description here

This cute little abuse of UML contrasts the direction of source code dependency with the direction of flow of control. This is where the answer to your question can be found.

In a using relationship:

enter image description here enter image description here

flow of control goes in the same direction the source code dependency does.

In a implementing relationship:

enter image description here enter image description here

flow of control typically goes in the opposite direction the source code dependency does.

Which means you're really looking at this:

enter image description here

You should be able to see that the flow of control is never going to get from the Presenter to the View.

How can that be? What does it mean?

It means the view either has it's own thread (which is not that unusual) or (as @Euphoric points out) flow of control is coming into the view from something else not depicted here.

If it's the same thread then the View will know when the View-Model is ready to be read. But if that's the case and the view is a GUI it will have a hard time repainting the screen when the user moves it around while they wait for the DB.

If the view has it's own thread then it has its own flow of control. That means to implement this the View will have to poll the View-Model to notice changes.

Since the Presenter doesn't know the View exists and the View doesn't know the Presenter exists they can't call each other at all. They can't fling events at each other. All that can happen is the Presenter will write to the View-Model and the View will read the View-Model. Whenever it feels like it.

According to this diagram the only thing the View and the Presenter share is knowledge of the View-Model. And it's just a data structure. So don't expect it to have any behavior.

That might seem impossible but it can be made to work even if the View-Model is complex. One little updated field is all the view would have to poll to detect a change.

Now of course you can insist on using the observer pattern, or have some frameworky thing hide this issue from you but please understand that you don't have to.

Here's a bit of fun I had illustrating the flow of control:

enter image description here

Note that whenever you see the flow going against the directions I defined before what's really happening there is a call is returning. That trick won't help us get to the View. Well, unless we first return to whatever called the Controller. Or you could just change the design so that you can get to the view. That also fixes what looks like the start of a yo-yo problem with Data Access and it's Interface.

The only other thing to learn here besides that is that the Use Case Interactor can pretty much call things in whatever order it wants as long as it calls the presenter last.

  • Thanks a lot for answer man, I've seen your answers on various other questions about the Clean Architecture. Are you suggesting that the View constantly check a flag, for example, within the View Model to see if there were any changes? Would the view then have to redisplay the whole View Model again, or should I use a set of nested flags to indicate which data has been changed? – Fearnbuster Oct 19 at 2:32
  • The view doesn't have to poll constantly. For example web 1.0 only polls when the user hits reload. Polling constantly is a design decision that should consider the users real needs. I'm just saying it's possible. The point of a update field is to make detecting an update fast. Only needed if the View Model is complex. Also consider what happens if the view reads while the presenter is halfway through an update. – candied_orange Oct 19 at 2:38
  • Okay, thanks a lot for the help. If/when you follow this architecture, is this the technique that you usually use? – Fearnbuster Oct 19 at 4:52
  • 1
    I think there is big mistake that this answer groups together design dependency and runtime dependency. The two can be different. – Euphoric Oct 19 at 6:40
  • 1
    @Euphoric Why thank you. I'm tying them together because if you don't have a source code dependency on something you can't use a runtime reference to it for anything since you don't understand what it is. All you'd be able to do is hold the reference like a collection does. If that's a mistake I'd like to understand it. – candied_orange Oct 20 at 14:35

I find this problem too confusing and it would take lots of text and time to properly explain the problem as I believe you misunderstand both Martin's Clean Architecture and MVVM.

First thing to note, is that the diagram you posted is incomplete. It only shows "business logic", but is missing some kind of "orchestrator" that actually makes the parts move in the right order. enter image description here

The code of orchestrator would be as simple as

string Request(string request) // returns response
{
    Controller.Run(data);
    Presenter.Run();
    return View.Run();
}

I believe I heard Martin talk about this in one of his talks about Clean Architecture.

Another thing to point out is that candied_orange's remark about lack of cycles is wrong. Yes, the cycled don't exist (and shouldn't) in the architecture of the code. But cycles between runtime instances are common and often lead to simpler design.

That is case in MVVM. In MVVM View depends on ViewModel, and ViewModel uses events to notify View about it's changes. This means that in the design of the classes, there is only dependency from View to Model classes, but during runtime, there is cyclical dependency between View and ViewModel instances. Because of this, there is no need for orchestrator, as ViewModel will provide View way to figure out when to update itself. This is why "notifications" in this diagram use "squigly" line and not direct line. It means View observes changes in ViewModel, not that ViewModel depends on View.

enter image description here

The most important thing you should take from Martin's Clean Architecture is not the design itself, but how you handle dependencies. One of the critical points he makes in his talks is that when there is a boundary, then all code dependencies crossing that boundary cross it in single direction. In the diagram, this boundary is represented by double line. And there is lots of dependency inversion through interfaces (InputBoundary, OutputBoundary and DataAccessInterface) that fixes the code dependency direction.

In contrast the ViewModel in Clean Architecture is just plain DTO with no logic. This is made obvious by <DS> tag. And this is reason why orchestrator is necessary, as View won't know when to run it's logic.

If I were to "flatten" the diagram into what will it look like during runtime, it will look like this:

enter image description here

So during runtime, the dependencies are in "wrong" direction, but that is fine.

I recommend watching his talk about Clean Architecture to better understand his reasoning.

  • Your "Orchestrator" shouldn't be calling the Presenter. The Use Case Interactor does that. – candied_orange Oct 19 at 13:13
  • @candied_orange True, that is a mistake. – Euphoric Oct 19 at 13:21
  • Thanks for the answer, it's always good to get a few different opinions. I upvoted both of your guys' answers. Do either of you happen to know if Robert Martin has a code base somewhere in which he implemented a form of his Architecture? I looked at his FitNess project, but I couldn't see the forest for the trees. Also, am I correct in speculating that, even though the image I posted is the diagram that Uncle Bob always uses in his talks, it's actually just an example of what your architecture MAY look like? Whereas it can look very different as long as the dependency flow is correct? – Fearnbuster Oct 19 at 14:18
  • @Fearnbuster To your last question, yes. The direction of dependencies is more important than the structure. I believe that "Clean architecture" , "Onion architecture" and "Hexagonal architecture" are really implementations of the same idea of "Keep dependencies in check". – Euphoric Oct 19 at 14:41
  • @Euphoric Honestly, I would say that this is likely the case, because in a different image of his book (Figure 8.2 of Chapter 8), he shows an architecture that looks different. In that diagram, the Controller is actually a middle-man between the Interactor and the Presenter. There is also no Output Boundary for the Interactor; it seems that the Interactor receives requests through an interface, and then returns the responses through the same interface (I assume this is done through a simple function return value, as I can't think of any other mechanism that would work that way). – Fearnbuster Oct 19 at 15:41

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.