- Is there are any practical grouping of the output port, it seems that the output port is a collection of abstract / interfaces which is linked to the one use case. so, say if we have 5 use cases, which produce some output data, and there is a delay for some time between the use case is triggered and the result is reported, so it means we have to also take care of it. this will make the output port have 5*2 interfaces now, to be implemented by the presenter.
EDIT
i mean the loading wait between when the usecase is triggered and the outport is produced, So we had two interface per usecase one to report the loading time, one report the data once the loading is completed.
So when you want to report the progress of the use case you have multiple options.
Add a progress method to the output port
public interface OutputPort {
public void setResponse(ResponseData rd);
public void reportProgress(Progress progress);
}
Extend a progress interface
public interface ProgressOutputPort {
public void reportProgress(Progress progress);
}
public interface OutputPort extends ProgressOutputPort {
public void setResponse(ResponseData rd);
}
Progress response data
public class ResponseData {
Progress progress;
??? result;
}
Extend progress response data
public class ProgressData {
Progress progress;
}
public class ResponseData extends ProgressData {
??? result;
}
I can't go into all the different pros and cons here, but I guess I would use either the 2. or 4. option.
- coming to the presenter in the web application, the web application has a lot of pages, which can be called views. so, do we create a single presenter that implements all the use-case output interfaces? and the presenter decides which view to render, what data. ? the problem with this approach is that it makes the presenter one very big class which implements all the use case output. Or do we create one presenter for each UI page, which implements only relevant use case output port.?
The concept of a presenter doesn't mean that there is only one. Furthermore if there would only be one it would have a lot of responsibilities and thus change for different reasons. This would be a violation of the single responsibility principle. This doesn't necessarily mean that you have to create a new presenter for each output port. But usually the difference output ports change for different reasons.
I also guess it will be better to separate the different presenters, because of testing reasons. E.g. if you only have one presenter that implements all output ports, it also has dependencies to all view models that it can update. This means that you often have to mock dependencies for one test that are not necesarry for that specific test.
- the same question goes to the controller, whether to have one big controller of many small controllers per view.
The same answer as I gave about 2. the presenter can be applied to controllers.
Controllers execute use cases based on user interaction. This can be a click to a button, a fingure gesture on a touch device, a state change of the gyro sensor of a mobile device or whatever a user interaction can be. Thus controllers are triggered by events that the ui emits. The controllers interprete user interactions and translate them to a use case call by passing user input from view models to the use case. You often encasulate the updating of the view models with the result of the use case by using a presenter.
EDIT
so, its better to have presenter and controller per page. ?
Yes and even more fine grained. Maybe a use case only applies to a part of a page and thus you have a controller for that part and a presenter as well.
There might be situations when you can merge presenters and/or controllers into one object, but I guess this cases are rare. Finally you will see it when the application evolves. Sometimes you merge objects and later you find out that it wasn't a good idea and you split them again. Maybe into the same structure as they were before you merged, maybe you find another structure more suitable.
