[forge-dev] Wondering about coding convention #philosophy

Vineet Reynolds Pereira vpereira at redhat.com
Tue Oct 22 11:54:02 EDT 2013



----- Original Message -----
> From: "Antonio Goncalves" <antonio.mailing at gmail.com>
> To: "forge-dev List" <forge-dev at lists.jboss.org>
> Sent: Tuesday, October 22, 2013 3:06:12 PM
> Subject: Re: [forge-dev] Wondering about coding convention #philosophy
> 
> >> * 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

Tracking as FORGE-1277 <https://issues.jboss.org/browse/FORGE-1277>.

I'll just reproduce my comments posted there to carry on the thread:

In my opinion, this is a good addition to have. We should however handle the scenario (or the equivalent ):

If a client issues a GET with a filter parameter (like filterAllWithBooks), then the resource representation should not be used in a subsequent PUT request to update the entity. The resource representation used in such a PUT request would lack certain relationships, and thus such requests would result in incorrect updates.

I believe this could be done via documentation - clients should not be using filtered representations to represent updates in entities. Also we do not support HTTP PATCH (yet), so we should accept resource representations in whole and not in bits. It may also be necessary to ensure that the relationships are eagerly fetched by default (debatable on whether we should require clients to take the additional step of using the filter parameter to request the complete entity representation).

> 
> 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 | Twitter | LinkedIn | Paris JUG | Devoxx France
> 
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev


More information about the forge-dev mailing list