Develop Reference

Vaadin7 architecture

We are currently planing our project and decided to use Vaadin. Right now we are a bit stuck figuring out how we could organize our code quite well without spending to much time. It seems MVP is a good practice for vaadin, but we are all new to the framework and it seems that quite a few people are really struggling with it. During our research we noticed that there are only very abstract tutorials and outdated frameworks. In the vaadin book also a layered architecture is recommended which we wanted to use. Our application isn't too complex (comparable to a usual businessbackend).
Is there maybe an elegant and simple solution to decouple the view,while also using the Designer?
We are also planning to use Spring Security and UI.
Thanks in advance

In my latest project I'm using Spring alongside with Vaadin and, although lots of boilerplate is added, your classes will be smaller, better organised, with single responsibility. In my case, I follow the architecture below:
Layout: class that contains the UI elements and it's design/layout.
Controller: handles all the events and user actions that a layout has. A controller only responsible of a single layout.
View: View class is the main "controller" for a specific URI fragment. If it gets too complex or with subviews, a controller class is created and injected.
Service: contains the business logic of the data. While the "Controller" handles the user interaction, the service is responsible of the business logic and data.
Repository: SpringData JPA repositories. Implement the CRUD operation and custom queries.
Model: Database entities.
Extra packages:
Event: I recommend using EventBus alongside the application.
Helpers: For that stuff that you don't know where it really fits in.
Configuration: Configuration and properties fetched from application.properties (if using SpringBoot).
Using this pattern you'll avoid ending up with spaghetti code and mixing up responsibilities on the same class. Regarding the Vaadin Designer, with this pattern it's completely independent as your layout can either be pure java or the pseudo-html.

Play Framework separate business logic

I come from J2EE background and am trying to write an application with Play and angular js. The application is basically a booking app which basically looks like this:
https://gb.youcanbook.me/demos.jsp?template=generic&theme=city
Up until now all things were nice and easy but now there's a design decision that I need to make. In the Play framework, as I understand, the routing happens under Controller and the business logic goes under Model classes. Model classes essentially are EBean annotated domain classes. As per my limited understanding, this is where all the heavy lifting of the application/business logic needs to happen.
Coming from a J2EE background, my mind poses a question. Is this the right way to go? I know I can easily create another service class and just call them straight away from the Controller. But, is that the right way to go? Or has Play! just given us the freedom to go whichever route we want to take?
Also, in my case, I am using Firebase as my backend store so #EBean annotated classes don't make much sense. I can use spring but I don't want to take that route as that would mix in J2EE flavour which I want to avoid for the time being.

It's possible to have multiple controllers per model (mvc architecture)

I'm developing a java desktop application and I decide to apply the mvc architecture
I read the oracle tutorial
In this tutorial, the writer used one controller for all models.
It is possible to use more than one controller in my application and how those controllers can communicate between them ?

What I normally do, for simplicity and to keep views and controllers cohesive.
Having one controller and view pero function simplifies the modification of those, and simplifies the debugging process.
Normally you will have a main entrance to the application, from wich you will navigate to the diferent views. When creating the other secondary views, as those are dependant of the main one, you can create a reference between them, in order to allow them to comunicate.
Thats what I normally do.

Is MVC necessary for a client-server application?

Currently doing a group project for college in Java. The assignment is to produce a zero-conf based distributed system. Our group decided on a conference chat application, using client-server architecture. As I joined the group late, a bulk of the code was already completed, and they had decided to develop an MVC architecture for the project. I have experience myself with MVC through Rails development, and can appreciate how handy it is in that context. However, I can't see the benefits of using it the way it has been implemented by my group.
There are two classes for Client and Server, each of which contains methods for sending and receiving datagrams, and fields such as sockets to enable the sending. There are also ServerController and ClientController classes. Each of these classes consists of only one field(a Server and a Client respectively), and all the methods are either wrappers for the public methods of the Server or Client, or simple utility methods. An example would be:
public void closeDownServer(){
server.closeDownServer();
}
To me, this seems completely pointless, and that in this instance MVC has been implemented just for the sake of using a design pattern. Can anyone tell me if there is any benefit to coding the application in this way? Is there any need for these controller classes at all?

The purpose of MVC is to provide abstraction to make later changes easier to implement, and to decouple your components. That might be why you see it as pointless now.... because your application is small and simple. If it will stay that way, then MVC might just be added bloat to your application. But if it's going to grow, MVC might be helpful for future development.
Consider a few cases that might illustrate why you would want to use MVC or an implementation that let model and view access each other directly, without a controller.
What if you need to perform some other actions when "closing the
server" that aren't related to your server class specifically? Where
would you do this?
What if you wanted to change your server implementation to a third party package? Would you rather change your controller code or change
implementation specific code in all your views?
What if you change the database you are using to store application data? Do you want your UI developers worrying about changing code in
the front end to accommodate this?
All of the above situations can be mitigated by using MVC, which will give you the proper separation of concerns and abstraction necessary to make developing and improving/changing code easier.

with a description this deep it is impossible to say if MVC pattern really is valid to your design or not.
But I can say this: there is a pattern far more important pattern than MVC pattern - the pattern of SIMPLICITY: if something in your code is completely useless and doing nothing, GET RID OF IT! There is no point having some class just because of some authority once said so.
Quite often when implementing MVC model, I have seen the controller combined with the view, especially when the app is simple. So you are not alone making this question. Later, if the requirement arises (multiple different views for instance) you can separate the controllers.

The controller means that you can change the behaviour of the view binding to the model (i.e., user input is transformed into the model by the controller). In this context, I'd say that a controller generally isn't needed, since you won't need to change this behaviour in the future.
When developing games and I need to implement MVC, I normally leave out the controller too (it's combined with the view).

How to make right architecture in Web application using Vaadin framework? Please Help!

HI, I am starting to developing web application and decide to use Vaadin + Java EE for reusable business logic. I know that Vaadin has MVP design pattern, but how to make good hierarchy of classes, write all in one MyApplication.java or make own Button classes or make Listeners in one side and UI components in other, and how to combine it with MVC design pattern of Servlet specification.
I am beginner in developing project from zero, please Help!

In Vaadin a good OO approach is to split your UI logic into custom components that implement a single piece of application UI and maximize the re-usability.
Inherit CustomComponent and build the user interface there and add all event handlers there too. Publish only logical API. The same applies to events. For example: The class OrderEditor extends CustomComponent with functions like setOrder(Order) and getOrder(). Where Order is your business class. Builds a UI for manipulating the Order object. Optionally calls saveOrder(Order) in your service API or sends a OrderChanged event to be handled elsewhere.
It has also been argued that CustomComponent is not much different from the Layout classes. That means it shouldn't make a big difference to extend those instead of CustomComponent. However, the main point here is that you are composing logical pieces of UI with logical business API - publishing only minimal amount of Vaadin APIs that let you manipulate the internal implementation of your component.