How does MVP fit into the Java Case Study? Clean Architecture with AngularJS+Java EE?

[Dirk Dreyer-Hochstein]

Hi,

I work on a project where I implement the UI with AngularJS and try to use the same method as Uncle Bob in his Java Case Study to develop this project. But now I stuck because when I compare the current implementation of the use case (PresentCodecast) and some of the architecture in his Videos (I think its in Episode 14) then I am confused. 

Look on the pictures I took from the videos:

The problem is that I want to use any framework like CDI, JAX-RS and other stuff only in the web-implementation (Controller/Services and Presenter). I don't want to use Annotations for Java EE and so on in my core. I think its possible but I have the problem that the example don't use any Boundary at the moment and the test returns the codecast directly with a "presentCodecast"-Method.

When I look on the diagrams (pictures), I understand that I should use the presenter inside the usecase to interact with the view and that the controller use the usecase to execute any "command". But which commands are reasonable inside the controller and which in the presenter? What if I only want to load a list of code casts (as example with a reload-button). Is the reload method on the presenter because I only get a new List of Models or do I need to use a command with the controller and notify the presenter that the view should reload? 

Anyway then I get another problem because the communication is with JSON/REST from AngularJS and I need to know that I executed a command and listen on another URL to get reloaded items. This way sounds not correct. Later I want to use a reactive approach and it seems then I have a problem with asynchronous execution. 

Has anybody implement an application with AngularJS and Java EE as Backend? Or any tips?

A little help would be appreciate :)

[unclebob]

Keep in mind that the Java Case Study episodes do not present the system in it's final form.  As we develop it, we'll be violating lots of rules, and failing to see lots of boundaries.  But as time goes buy we will refactor as those violations and boundaries become obvious.

Software development is not the art of getting things right the first time.  It is the art of gradual and incremental improvement.

[Dirk Dreyer-Hochstein]

Thx for your answer. I thought that this is not the final state but hoped to get a hint from the case study. At moment I refactor my application to clean it up and make it simpler. But I have a problem to integrate the MVP-Pattern. Can you give me a hint how you would integrate an AngularJS Client with REST as a View and Websockets as real-time messaging? I think I should use an abstraction so that the use cases don't know about REST and Websockets (Real-Time-Messaging) but when I tried to integrate it with the MVP Pattern I have the problem that I don't see if I need only one Presenter and an abstract View on the server side for REST/Websockets or many Presenter for different implementations. 

Because of the request/respone scheme of the REST-API I don't see how I can separating the Controller and the Presenter. As example: When you use a query for some resources. How would you involve the controller and presenter? A direct GET-Message to the presenter because I wait for the answer or do I need a controller which operate as presenter sometimes?

[David Hunt]

Hi Dirk,

I’ve implemented clean architecture in web applications a few times now and I had all these sorts of questions in the beginning as well. I think the most helpful piece of advice I can give you is this:

A web app is actually two apps; one client app written in javascript and executed in the browser, and one server app. Try to keep the two separate in your mind. Imagine you’re developing a thick client app for your favourite app store and a supporting back-end server app. The web is only different because it's the server app which delivers the client app to the user rather than the app store - and it delivers it in discreet chunks as needed (pages).

These two apps each need their own clean architecture. In the client there will be a core component of javascript which does not know about AngularJS or about the libraries you’re using to implement http requests or web-socket connections back to the server. It will contain all the logic of the client use-cases but have no idea how it will be ultimately connected to the view (DOM) and server.

As you write this javascript core (and I suggest you start by writing that first rather than anything involving Angular) you will start to make decisions about how best to interact with the presenter on the other side of the boundary. You will define the style of interaction that works best for your UI use cases. Will they return results to the presenter? Will they call methods on the presenter or assume the use of some sort of data-binding and set properties on the presenter instead? Essentially your answers to these questions will define whether you’re using the MVC, MVP or MVVM patterns of view and model separation, but don’t get too hung on up on the subtle differences in these patterns because it really doesn’t matter and they’re interchangeable. I always call it a presenter regardless of the style I choose to make life easier.

Hope this helps.

[Dirk Dreyer-Hochstein]

Hi David,

thanks for your hints. I have separated both in different artifacts and developed the Javascript-Client with TDD without any backend. It works fine but at the moment I use AngularJS directly as Dependency-Framework and for the Components. I did not wrote my own core because I am not the best javascript developer. But because I used TDD I think it's the simplest implementation which works.

My problem is more the connection between the client and the server because we want to use REST (HATEOAS) to decouple the client from the api of the server. 

I think I will implement the simplest possible solution and then try to clean it up like Uncle Bob do ;).  Like Uncle Bob said: "Software development is not the art of getting things right the first time. It is the art of gradual and incremental improvement."

[Sebastian Gozin]

Perhaps it helps but while working on a similar project I felt like REST calls do not practically represent resources/entities as some tutorials want you to believe.
They feel more like event/usecase triggers to me.

For me this meant that in the client (angular) application I did not have a CRUD like gateway but rather an IO channel implemented with REST or a web socket.

[Paul Bouzakis]

Agree with Dirk on the approach.

I've come to the same conclusion as well. The client side app is it's own app compared to the server side app. I realized this when I revisited the hexagonal aka ports and adapters architecture. As you can see from this image: http://alistair.cockburn.us/get/2301, one port connects to  another app (in this situation it would be the backend server). 

The current setup I have has a Knockout "plugin" for my UI delivery implementation. With Knockout being an MVVM UI library, I have ViewModel and View objects on the that side of the boundary. If the view is dynamic and can we swapped out or needs any special handling I sometimes create a Presenter object to manage the view. The view model is always present for the view to bind to. Angular has a very similar setup (it's really MVVM more than MVC).

Currently these objects make calls into the application or use case layer. Usually the last argument is a delegate object (aka a listener object that has callbacks for specific hooks). One of these hooks is usually used for any updates that are made to the original response model. This is used to keep the UI current.

I'm still working out the best way to do this, as the app is not 100% consistent as we are still in the process of nailing down an implementation that works for us.