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.

Java server side form validation using DTO and hash map

I am developing an app using MVC pattern.
Controllers: servlets
Model: I am following DAO/DTO pattern for accessing database
View: simple JSP EL and JSTL
For accessing database I am using DAO pattern. I want to put validation method and a HashMap for error messages inside the DTO classes for validating FORM data, something similar to Putting validation method and hashmap into DTO.
My question is - this a right approach? If not what is an ideal way for doing this?
As a summary: I want to know real world solutions for server side form validation when we are using DAO/DTO pattern. Please help me.

I believe you need to treat separately the architecture you're implementing and the frameworks you're using to implement the architecture.
Java has a rich set of tools for working on the three standard tiers of your application and choices depend on some factors like expected load and server resources, if you have a two or three users application then it is just a matter of taste.
In terms of DAO/DTO then you have also some options, for example you can build your Data access layer with hibernate and then for your service layer API use DTO's. In this situation you probably want to use a tool for mapping between your domain model and your DTO's (for example jDTO Binder).
Another common approach is to use Spring JDBC Template, there you can go a little bit more crazy and use the same Domain objects as part of the Service layer API.
Finally, the truth is, you can do this by the book or you can do it completely different choice is based on your scenario, taste and experience.

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).

spring mvc dao and service bean mapping

I am new to Spring and hibernate.
I am trying to learn the best practices and design methodoligies in j2ee apps.
I have a managed to create a basic spring mvc web app. now lookin for that
- how should i map my service beans to dao beans or should just use dao beans only.
- Is there any need to make DAO classes singleton
- If i use same dao bean for the jsp, then e.g. onSubmit if I have to enter data on multiple tables (dao beans) then how would I do that.
1 service bean to more than 1 dao beans??
and any refrence material on designing good web app using spring hibernate would appreciated ;)
thanks

You must use service bean. service logic should be there only.
DAO should only for DB related operation.
Now you can inject multiple DAO in your service bean.

FWIW - I just went through a similar learning process on Spring. The good news is, there are a lot of examples out on google; the bad news is, there are not a lot of "complete" examples that are good for rookies (also if you are going to target v3 Spring, there is a lot of pre-v3 stuff out there that can be confusing based on the new baseline). What worked for me was the following: started with the sample applications on the SpringSource site (http://www.springsource.org/documentation). Between their handful of examples, there are just about all the pieces you will need, at least in minimal form. When I found something in those examples that I needed, I googled based on similar terms (some of the # annotations etc) to find more complete information/better examples on that given topic. Many of those searches led me back to this site, which is why I started frequenting here - lots of good questions already answered. I guess this isn't an overly insightful answer, but this process got me up and working through the basics in a fairly quick amount of time.

DAO layer and service layer are different entities:
DAO is responsible for getting and putting single objects from\to DB. For example, get User(id, name, lastname) from DB.
Service layer is responsible for your business logic. It can use several DAO objects for making one action. For example, send message from one user to another and save it in sent folder of first user and in inbox of recipient.

A service is about presenting a facade to the user that exposes business functions that the user can take. Basically, if you have a set of low-level use cases, the methods on the service would line up with individual user actions. Services are transactional, generally if the user does something we want all the consequences of that action to be committed together. The separation between controller and service means we have one place to put webapp-specific functionality, like getting request parameters, doing validation, and choosing where to forward or redirect to, and a separate place to put the business logic, stuff that doesn't depend on webapp apis and is about what objects get updated with what values and get persisted using which data access objects.
I see a lot of cases where people seem to think they need one service for each dao. I think their assumption is that because Data Access Objects and Controllers and Models are fairly mechanical about how they're defined, services must be the same way, and they construct them with no regard for the use cases that are being implemented. What happens is, in addition to having a lot of useless service boilerplate code, all the business logic ends up in the controller jumbled up with the web-specific code, and the controllers become big and unmanageable. If your application is very simple you can get by with this for a while, but it is disorganized, it's hard to test, and it's generally a bad idea. Separation of concerns, keeping infrastructure code in one place and business code in another, is what we should be aiming for, and using services properly is very helpful in getting there.

Seam application Architecture

I need to implement quite big system in Seam. I'm considering the way of designing the architecture. If it's good to use page controllers or application controllers or front controller or every each of them. If it's helpful to use backend bean or maybe there's no need to do that. If you have any suggestion or link to helpful article I will appreciate it.
Thanks a lot!
Daniel Mikucki

If you need to learn a lot about Seam for a project, I recommend you get the Seam In Action book, which is the best on the subject.
To answer your question, personally I prefer to use the pull-MVC style in Seam, where you refer to data in your view templates that Seam takes care of initialising, as needed, using #Factory methods. However, there is more than one way to do it in Seam, so it is worth reading about the alternatives first, hence the book recommendation.
Alternatively, build a few Seam applications first to throw away before you try to build one 'right' :)

Daniel,
It is good practice to use a front controller, most people aren't aware of that design pattern.
It is a really good design pattern to use because it ensures you are accessing the application through a single entry point. You can monitor everything that comes and goes easily with less configuration. You reduce the amount of possible code duplication because there is a single entry point. In addition to having less code to maintain, the code should be easier to follow since there is only one way in. You can then easily follow the execution flow of the application.
Unfortunately for Seam, there isn't really a front controller pattern. I haven't spent as much time as I would like to develop my own, but security and audit-ability are my number one focus.
As far as page / application controllers go, in Seam, you have more contexts or scopes available. Event, Page, Conversation, Session, Application, to name most of them.
If you're developing a controller or in Seam, a page action, most of the time, it will be event based. That is the shortest lived scope. If you have page flows, you would then use conversational-scoped components.
Take a look at the examples in the source code. You can do a lot with very little code, it is amazing, but at the same time, there is a lot going on that may take a while to pick up on.
The n-tier design that most places follow doesn't necessarily apply here. For most of my pages, I define a query that I'll use in XML (entity query), then I'll inject it into my page action and call it there. So instead of having a controller, service, dao, and entity classes, you end up with simply a page action, the queries, and entity classes. You can cut out the service and dao layers in most cases.
Your whole definition of a service might change too. For me, a service is a service provider such as notification, security (auditing), exception handling, etc. all of these services run in the background and are not tied to a particular http request.
Walter

Daniel,
I have used one controller per page, one service and one dao per entity.
Use case logic goes in the controller
Entity specific business logic goes in entity service.
Actions which span multiple entities you can create a facade service - something which sits between controller and entity services
While the above is a good and practical approach, ideally:
you could break out any non MVC code from controller into its own service class, ie. 1 service class per page
you should only access the entity dao via the entity service.
Here's how the control would flow:
Ideally:
UI
-> PageController.java
-> PageService.java
-> EntityService.java
-> EntityDao.java
Practically, you could trim down a few layers:
UI -> PageController.java -> EntityService.java
Or for actions touching multiple entities:
UI -> PageController.java -> Facade.java -> Entity1Service.java,Entity2Service.java
PageController.java would be a Seam #Component and in your ui you can refer it as:
#{pageController} and pull the data from the view.
In architecture, the most important thing is how you layer things in the stack is avoid circular dependencies between layers. For example, Entity Service should not reference Controller and so on.
The other important thing is to be consistent about layering in the entire application. Use code generators if you can to keep your code consistent across the application, it really pays off for large projects. Look into Clickframes if you are interested in code generation (Clickframes generates starter code for Seam apps with full JPA/valdiation/security support which you can then modify). See this Seam demo build with Clickframes if interested.