<div dir="ltr">>> * JSF : getAll<br>>> * REST : listAll<br><br>> They do look similar, but they're not the same in all respects.<br>> The one in REST will contain JOIN FETCH expressions when relationships (@OneToMany, @ManyToMany etc.) are found in the class.<br>
> This was done to ensure that serialization would not emit incomplete object graphs.<br><div class="gmail_extra"><br></div><div class="gmail_extra">When you have too many @OneToMany or @ManyToMany relationships, you end up with several queries that JOIN FETCH several/different relationships. So what I usually do when things are complex is :</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">findAll</div><div class="gmail_extra">findAllWithRelations (meaning all relations are FETCH)</div><div class="gmail_extra"><br></div><div class="gmail_extra">or more specific (when things are really really complex)</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">findAllWithBooks</div><div class="gmail_extra">findAllWithAuthors</div><div class="gmail_extra">findAllWithBooksAndAuthors</div><div class="gmail_extra"><br></div>
<div class="gmail_extra">Antonio<br><br><div class="gmail_quote">2013/10/21 Vineet Reynolds Pereira <span dir="ltr"><<a href="mailto:vpereira@redhat.com" target="_blank">vpereira@redhat.com</a>></span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
<br>
----- Original Message -----<br>
> From: "Antonio Goncalves" <<a href="mailto:antonio.mailing@gmail.com">antonio.mailing@gmail.com</a>><br>
> To: "forge-dev List" <<a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a>><br>
> Sent: Sunday, October 20, 2013 10:20:49 PM<br>
> Subject: [forge-dev] Wondering about coding convention #philosophy<br>
><br>
> Hi all,<br>
><br>
> I love Forge because it generates code. And that's why my customers start to<br>
> love it too. Basically, they look at Forge as the "way to write Java EE<br>
> code" or if you like "if those guys write code like this, then we should".<br>
><br>
> I am digging into some details of the generated code (I am writing a blog<br>
> about several architectural styles starting with Forge) and I feel coding<br>
</div>> convention should be homogenized . I know extensions are written by<br>
<div class="im">> different individuals, but some basic coding conventions should be applied.<br>
<br>
</div>+1.<br>
<br>
I would consider these architectural styles more than coding conventions,<br>
and I believe it would be wise to 'standardize' some of these for Java EE 6+.<br>
<div class="im"><br>
> For example, when you generate a web app with REST and Faces scaffolding,<br>
> you get some difference :<br>
><br>
><br>
</div>> * Faces Backing Bean use query builder (e.g getAll method is<br>
> entityManager.createQuery(criteria.select(criteria.from(Book.class))).getResultList();<br>
> and<br>
> * REST Endpoint use dynamic queries (the list all method is "SELECT<br>
<div class="im">> DISTINCT b FROM Book b ORDER BY <a href="http://b.id" target="_blank">b.id</a> "))<br>
> Method names are different and do the same :<br>
><br>
><br>
</div>> * JSF : getAll<br>
> * REST : listAll<br>
<br>
They do look similar, but they're not the same in all respects.<br>
The one in REST will contain JOIN FETCH expressions when relationships (@OneToMany, @ManyToMany etc.) are found in the class.<br>
This was done to ensure that serialization would not emit incomplete object graphs.<br>
There are various factors that would be at work here in determining what JPQL queries should be generated.<br>
Obviously in this context, exposing JPA entities directly is bad idea and projections/views of the entities should be used instead.<br>
<br>
IMHO we should not be putting persistence concerns in either the JSF beans or the REST resources.<br>
They should go into a service or a repository or whatever data access pattern is suitable for the context.<br>
This is where we lack any standardization at the moment, and it would be better to not limit this exercise to improving the conventions alone, but also the architecture.<br>
<br>
I don't believe in packing in persistence concerns however small, into these beans for<br>
* we run the risk of generating God classes, and<br>
* we'd leave users with the task of creating/extracting the persistence layer (which should have been done by Forge in the first place).<br>
<br>
><br>
> Attributes<br>
><br>
><br>
> * private EntityManager em;<br>
> * private EntityManager entityManager; // em would be better<br>
<div class="im">> Or the use of this keyword (JSF beans use this.entityManager instead of<br>
> directly em in REST)<br>
><br>
> And there are several examples like this. If Forge is seen as "the way of<br>
> writing code" maybe something should be created to get homogenized code.<br>
> PMD, Checkstyle, human review and so one.....<br>
><br>
> Just wondering....<br>
><br>
><br>
> --<br>
> Antonio Goncalves<br>
> Software architect and Java Champion<br>
><br>
> Web site | Twitter | LinkedIn | Paris JUG | Devoxx France<br>
><br>
</div><div class=""><div class="h5">> _______________________________________________<br>
> forge-dev mailing list<br>
> <a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
_______________________________________________<br>
forge-dev mailing list<br>
<a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Antonio Goncalves <br>Software architect and Java Champion<br><br><a href="http://www.antoniogoncalves.org/" target="_blank">Web site</a> | <a href="http://twitter.com/agoncal" target="_blank">Twitter</a> | <a href="http://www.linkedin.com/in/agoncal" target="_blank">LinkedIn</a> | <a href="http://www.parisjug.org/" target="_blank">Paris JUG</a> | <a href="http://www.devoxx.fr/" target="_blank">Devoxx France</a>
</div></div>