GWT + entities + JPA + DTO + Dozer - gwt

I am wondering what is the best way to handle mapping of entity beans (JPA 2) to DTOs.
Since you cannot use entity beans "directly" with GWT, you need to handle DTOs instead.
I have several entities with various relationships (OneToOne, OneToMany, ManyToMany with a join table etc).
Initially i started converting all entities to DTOs by hand with the help of a class MyEntityTransform.java with methods like :
static final public CarBean persistant2Bean(CarPersist) {
return new CarBean(cartPersist.getId(), carPersist.getName(),
carPersist.getDescription());
}
Other methods are : persistent2BeanCollection(...), persistent2BeanMap(...), bean2Persistent(...), bean2PersistentCollection(...)
That becomes a fastidious task when handling collections, especially when the same entity has references to several other entities;
I have been thinking about using the DOZER framework to handle the mapping between entities and DTOs.
It is mentionned here : http://code.google.com/intl/fr/webtoolkit/articles/using_gwt_with_hibernate.html
However i am not sure how well it handles the various JPA mappings (manytomany for instance) and how much work it is to configure it in the dozer-bean-mappings.xml file.
Also i guess this framework is intensively using reflection to perform mapping operations. Such approach is much slower than mapping performed "by hands", e.g. when i use the methods in my MyEntityTransform.java class.
What do you suggest ? i'm interested in everybody's experience handling JPA entities with GWT.
Thanks.
Celinio
http://www.celinio.net/techblog

In first instance I would always prefer Dozer. When the DTO structure is the same as your entities, you can use Dozer with zero configuration by simply calling the map function. When your DTOs differ from your entities the configuration overhead is minimal. Simply look in the really good documentation.
When performance becomes an issue, I would prefer a code generator approach, but I would never write the mapping code by myself cause it can be very error prone.

If you want to just include entities in you EJB or JPA module in your GWT module follow these steps. I found it out my own and It worked for me.
Include your EJB module in GWT module's build path (you may have already done that)
Now goto your entities package in EJB module (i will take it as "com.ejbproject.entities")
Create a file named Entities.gwt.xml (<ProjectSourcePath>/com/ejbproject/entities/Entities.gwt.xml)
File content should be
<module>
<source>com.ejbproject.entities</source>
</module>
Now include following fragment in your GWT project's <modulename>.gwt.xml file.
<inherits name="com.ejbproject.entities.Entities"/>
Now you can include Entities in your GWT client side and gwtCompile without any problem

Related

How to use class abstraction with JDL?

I'm doing a project for my last year of university.
I have to make a commercial website using JHipster (in my case Angluar + Spring + PostgreSQL).
Using JDL, I figured out that abstract classes seems to not be supported, therefore it seems impossible to use inheritance. Do you know how to bypass this issue?
Here is the jdl : https://framabin.org/p/?0ec3f3890f12aded#Xum+8i00kbP8p2jGhIVSXgu3Twc8BdwJ5iJ5t6cM/7A=
As you found out there's no support for inheritance in JHipster generated entities, so either you code it manually using Hibernate strategies or by replacing inheritance by composition which is often a good idea.
You could also compose by using one-to-one relationships and using DTOs to present joined entities as a single object.
In any case, you'll probably going to modify substantially the generated views in Angular code.

Should JPA entities and DDD entities be the same classes?

There are classes that are entities according to DDD, and there are classes that have #javax.persistence.Entity annotation. Should they be the same classes? Or should JPA entities act just as a mechanism for a mapper (https://martinfowler.com/eaaCatalog/dataMapper.html) to load DDD entities from a database (and store them) and be kept outside the domain model?
Would it make a difference if database metadata were separated and stored externally (for example, in XML)? If such classes are entities, where is the boundary? I think classes generated from XSD (for example, with JAXB) or even from database with MyBatis Generator are not entities as understood in DDD.
That's an implementation detail really. They could be or they could not depending on the flexibility of your ORM. For instance, if your ORM allows to map your domain objects without polluting them with persistence concerns then that's the approach that requires the less overhead and which I'd go for.
On the other hand, if your ORM is not flexible enough then you could go for a pragmatic hybrid approach where your AR and it's state are two different classes and where the state class is simple enough to easily be mapped. Note that the AR would still be responsible to protect it's state here and the state object wouldn't be accessed directly from outside the AR. The approach is described by Vaughn Vernon here.
Your JPA entities should be the domain entities. Why?
Your domain entities should express some strong constraints, e.g. by
Having parameterized constructors
Not exposing all setters
Do validation on write operations
If possible, a domain entity should always remain a valid business entity.
By introducing some kind of mapper, you introduce a possibility to automagically write arbitrary stuff into your domain entities, which basically renders your constraints useless.
The other option would be enforcing the same constraints on JPA and domain entities which introduces redundancy.
Your best bet is keeping your JPA entities as ORM-agnostic as possible. Using Hibernate, this can be done using a configurating class or XML file. But I am no Java EE/JPA guy, so it's hard for me to give a good implementation advice.
After some more experience with JPA and microservices, I would say that I would most likely not separate them when using JPA, unless there's a reason that makes me do otherwise. On the other hand, entities in a single bounded context do not necessarily have to be only JPA entities. It's possible to have both entities mapped by JPA implementation and entities mapped from DTOs using other technologies (like JSON mappers) or manually.
I agree that both ways are possible. After programming some applications with DDD in mind, I find that this heuristic works well:
If you start from having an entity and not having JPA, it will probably be too hard to refactor an entity so that it can be used by ORM framework, so keep them separate
If you start from scratch, it is worth not distinguishing DDD entities from JPA entities

Which packages to place the #Entity Java beans and flattened Object beans (used only in Controller) is the most professional way?

As a yet "newbie" of JavaEE, say I try to implement a rather big RESTful API with Spring 4 and Hibernate and, the final JSON objects should be transformed to flattened Objects other than the original Java bean entities annotated with #Entity.
Due to the "out-of-the-box" feature of Spring and Hibernate, I am sure most programmers can easily get the work done. But as an experienced programmer, we would focus more on the code structure, design architecture so that the whole project is more maintainable and code is easy to read.
So my first question is the package structure:
where to place the Java bean entities annotated with #Entity? I have seen some people place them in the package called model, I am not exactly clear about their purpose anyway
Where to place the final flattened objects transformed from the Java bean entities? I placed it in the package called dto as this is data transfer object between the service layer and the controller layer
so I have the following package structure:
sample.model //place the #Entity Java beans
sample.dto //place the aforementioned DTO
sample.controller //place the controller class
Anyone can give some comments on it? Thanks in advance
There's two different ways to organize packages in Java project.
package-per-feature
package-per-layer
Comparison
But how to name your package it's really up to you.
In different projects, I faced with names like:
for entity: model, domain, entity
for DTO: dto, transport, response or request (depending on direction)

Entity Framework object materialization and dependency injection

I would like to be able to inject some dependencies (by using an IoC container) into entities just after they are loaded and materialized by Entity Framework (as a result of a query for instance).
It is possible to do so by hooking on the ObjectMaterialized event but I'm wondering if there is no better manner to achieve this as I use EF 6 and code first.
Any advices or ideas ?
Thanks
Riana
Although Entity Framework can be configured to allow dependencies to be injected into entities, I think it's safe to say that the general consensus (take a look at the opinions of Jimmy Bogard, Mark Seemann and me) is to not do this at all.
For me the main point is that classes like entities, DTOs and messages are very different from service classes. Entities, DTOs and messages are short lived objects containing runtime data, while services contain behavior, are often long lives and simply process runtime data (such as entities).
That doesn't mean that you can't use services into your entities though. As Mark describes here, not letting your entities use services lead to an Anemic Domain Model. But what this means is that entities shouldn't be part of your object graph.
Instead, if you are practicing DDD, your entities can simply accept dependencies into the domain methods that you define on the entities. Those dependencies can than be supplied by the command handlers that execute the use case. In other words, dependencies are injected into the constructor of a command handler, and when calling an entity's domain method, the command handler will supply the dependencies that this method requires (usually just one or two) to that method (method injection).

Generate POCO classes and the mapping for an existing database using Entity Framework

Is it possible to auto generate the POCO classes and the mapping with the database defined separately using Fluent API (instead of annotations) for an existing database? Instead of coding all these entity classes manually, I find it easier if they are auto generated and then I can change them as required if the names are not incorrect (plural or singular) or the some of the relationships are not correctly mapped etc. This will save lot of time for me compared to coding all the entity classes and relationships from scratch and I am not that familiar with the fluent API syntax as well.
Yes, i encourage you to use Entity Framework Power Tools CTP1
Reverse Engineer Code First - Generates POCO classes, derived DbContext and Code First mapping for an existing database.
hope this helps
The Power tools are incredibly slow to generate files. It takes over an hour to work on my companies database (has a lot of tables).
Instead take a look at this visual studio extension http://visualstudiogallery.msdn.microsoft.com/ee4fcff9-0c4c-4179-afd9-7a2fb90f5838
It generates cleaner code, WCF serialisation classes, and includes the database default constraints as part of the POCO ctor.
Disclaimer: I should mention that I am the author of this extension