[forge-dev] Wondering about coding convention #philosophy

[Antonio Goncalves]

>>     * JSF : getAll
>>     * REST : listAll

> They do look similar, but they're not the same in all respects.
> The one in REST will contain JOIN FETCH expressions when relationships
(@OneToMany, @ManyToMany etc.) are found in the class.
> This was done to ensure that serialization would not emit incomplete
object graphs.

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 :

findAll
findAllWithRelations (meaning all relations are FETCH)

or more specific (when things are really really complex)

findAllWithBooks
findAllWithAuthors
findAllWithBooksAndAuthors

Antonio

2013/10/21 Vineet Reynolds Pereira <vpereira at redhat.com>

>
>
> ----- Original Message -----
> > From: "Antonio Goncalves" <antonio.mailing at gmail.com>
> > To: "forge-dev List" <forge-dev at lists.jboss.org>
> > Sent: Sunday, October 20, 2013 10:20:49 PM
> > Subject: [forge-dev]  Wondering about coding convention #philosophy
> >
> > Hi all,
> >
> > I love Forge because it generates code. And that's why my customers
> start to
> > love it too. Basically, they look at Forge as the "way to write Java EE
> > code" or if you like "if those guys write code like this, then we
> should".
> >
> > I am digging into some details of the generated code (I am writing a blog
> > about several architectural styles starting with Forge) and I feel coding
> > convention should be homogenized . I know extensions are written by
> > different individuals, but some basic coding conventions should be
> applied.
>
> +1.
>
> I would consider these architectural styles more than coding conventions,
> and I believe it would be wise to 'standardize' some of these for Java EE
> 6+.
>
> > For example, when you generate a web app with REST and Faces scaffolding,
> > you get some difference :
> >
> >
> >     * Faces Backing Bean use query builder (e.g getAll method is
> >
> entityManager.createQuery(criteria.select(criteria.from(Book.class))).getResultList();
> >     and
> >     * REST Endpoint use dynamic queries (the list all method is "SELECT
> >     DISTINCT b FROM Book b ORDER BY b.id "))
> > Method names are different and do the same :
> >
> >
> >     * JSF : getAll
> >     * REST : listAll
>
> They do look similar, but they're not the same in all respects.
> The one in REST will contain JOIN FETCH expressions when relationships
> (@OneToMany, @ManyToMany etc.) are found in the class.
> This was done to ensure that serialization would not emit incomplete
> object graphs.
> There are various factors that would be at work here in determining what
> JPQL queries should be generated.
> Obviously in this context, exposing JPA entities directly is bad idea and
> projections/views of the entities should be used instead.
>
> IMHO we should not be putting persistence concerns in either the JSF beans
> or the REST resources.
> They should go into a service or a repository or whatever data access
> pattern is suitable for the context.
> 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.
>
> I don't believe in packing in persistence concerns however small, into
> these beans for
>  * we run the risk of generating God classes, and
>  * we'd leave users with the task of creating/extracting the persistence
> layer (which should have been done by Forge in the first place).
>
> >
> > Attributes
> >
> >
> >     * private EntityManager em;
> >     * private EntityManager entityManager; // em would be better
> > Or the use of this keyword (JSF beans use this.entityManager instead of
> > directly em in REST)
> >
> > And there are several examples like this. If Forge is seen as "the way of
> > writing code" maybe something should be created to get homogenized code.
> > PMD, Checkstyle, human review and so one.....
> >
> > Just wondering....
> >
> >
> > --
> > Antonio Goncalves
> > Software architect and Java Champion
> >
> > Web site | Twitter | LinkedIn | Paris JUG | Devoxx France
> >
> > _______________________________________________
> > forge-dev mailing list
> > forge-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/forge-dev
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>



-- 
Antonio Goncalves
Software architect and Java Champion

Web site <http://www.antoniogoncalves.org/> |
Twitter<http://twitter.com/agoncal>
 | LinkedIn <http://www.linkedin.com/in/agoncal> | Paris
JUG<http://www.parisjug.org/>
 | Devoxx France <http://www.devoxx.fr/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20131022/170880b1/attachment.html