Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.databases > #657 > unrolled thread

JPA: annotations or XML?

Back to article view | Back to comp.lang.java.databases

Contents

  JPA: annotations or XML? Ricardo Palomaes <rpmdisguise-java@nowhere.com> - 2013-12-16 21:48 +0100
    Re: JPA: annotations or XML? Arne Vajhøj <arne@vajhoej.dk> - 2013-12-24 23:11 -0500
      Re: JPA: annotations or XML? Stanimir Stamenkov <s7an10@netscape.net> - 2013-12-25 13:21 +0200
        Re: JPA: annotations or XML? Arne Vajhøj <arne@vajhoej.dk> - 2013-12-27 22:34 -0500
          Re: JPA: annotations or XML? Stanimir Stamenkov <s7an10@netscape.net> - 2014-01-02 11:31 +0200

#657 — JPA: annotations or XML?

Hi,

I'm trying to use JPA for the first time in a small to mid Java SE
project (I expect it be around 50,000 lines, comments included).

I've always been against libraries using declarative XML files since I
felt that it added burden and an additional hurdle to use them besides
coding. As result of it, I initially liked very much annotations over
XML files in JPA.

However, I'd like to design the application in such a way that it
could use a local database persistence (now) or one based in
webservices (as a future enhancement). I'm still learning, but it
seems that I should use a DAO pattern. This is not a requirement, but
a "nice to have".

I have two questions:

1) (This may be really naive) I've read that JPA acts in some way as a
DAO layer but, will the JPA architecture keep track of entity object
passing through a "real" DAO layer, used in a context unaware of JPA
(the application GUI classes, for instance) and later returned again
to the JPA through the DAO without too much hassle?

2) Would I be able, by using XML files instead of annotations in JPA,
to keep my POJOs completely clean, so I could use them in both JPA and
webservice persistence providers in a DAO architecture, with the web
service part not having to include any package from JPA?

I know the answer to both questions may be "It depends on your code
and design" and "Start coding and later refactor", so I'm just looking
for general advice, not definitive answers.

TIA

[toc] | [next] | [standalone]

#658

On 12/16/2013 3:48 PM, Ricardo Palomaes wrote:
> I've always been against libraries using declarative XML files since I
> felt that it added burden and an additional hurdle to use them besides
> coding. As result of it, I initially liked very much annotations over
> XML files in JPA.

But the XML config files centralized the mapping, which could certainly
be seen as an advantage.

But JPA went the route it did.

> However, I'd like to design the application in such a way that it
> could use a local database persistence (now) or one based in
> webservices (as a future enhancement). I'm still learning, but it
> seems that I should use a DAO pattern. This is not a requirement, but
> a "nice to have".

Yes - a DAL.

> I have two questions:
>
> 1) (This may be really naive) I've read that JPA acts in some way as a
> DAO layer but, will the JPA architecture keep track of entity object
> passing through a "real" DAO layer, used in a context unaware of JPA
> (the application GUI classes, for instance) and later returned again
> to the JPA through the DAO without too much hassle?

What do you mean by "keep track of"?

> 2) Would I be able, by using XML files instead of annotations in JPA,
> to keep my POJOs completely clean,

I believe you can. JPA supports XML files as well as annotations. But I
have never seen XML files used. It will cost you in training of people
for long term maintenance relying on such a rare feature.

>                                so I could use them in both JPA and
> webservice persistence providers in a DAO architecture, with the web
> service part not having to include any package from JPA?

Having JPA annotation on classes used outside DAL is a bit ugly.

An alternative approach is to have both real data classes and DTO
classes. But that duplicate some code.

All pros and cons ...........

Arne

[toc] | [prev] | [next] | [standalone]

#659

Tue, 24 Dec 2013 23:11:01 -0500, /Arne Vajhøj/:
> On 12/16/2013 3:48 PM, Ricardo Palomaes wrote:
>
>>                                so I could use them in both JPA and
>> webservice persistence providers in a DAO architecture, with the web
>> service part not having to include any package from JPA?
> 
> Having JPA annotation on classes used outside DAL is a bit ugly.
> 
> An alternative approach is to have both real data classes and DTO
> classes. But that duplicate some code.

May be one could use internally a subclass for the sole purpose of 
declaring:

@Entity
@AttributeOverrides({
    @AttributeOverride(name="foo", column=@Column("FUN")),
    ...
})
@AssociationOverrides({
    @AssociationOverride(name="bar", joinColumns=@JoinColumn("BAR_ID")),
    ...
})
public class MyDatabaseEntity extends MyBean {

    // Nothing in here.

}

Haven't tried it, though.

-- 
Stanimir

[toc] | [prev] | [next] | [standalone]

#660

On 12/25/2013 6:21 AM, Stanimir Stamenkov wrote:
> Tue, 24 Dec 2013 23:11:01 -0500, /Arne Vajhøj/:
>> On 12/16/2013 3:48 PM, Ricardo Palomaes wrote:
>>
>>>                                 so I could use them in both JPA and
>>> webservice persistence providers in a DAO architecture, with the web
>>> service part not having to include any package from JPA?
>>
>> Having JPA annotation on classes used outside DAL is a bit ugly.
>>
>> An alternative approach is to have both real data classes and DTO
>> classes. But that duplicate some code.
>
> May be one could use internally a subclass for the sole purpose of
> declaring:
>
> @Entity
> @AttributeOverrides({
>      @AttributeOverride(name="foo", column=@Column("FUN")),
>      ...
> })
> @AssociationOverrides({
>      @AssociationOverride(name="bar", joinColumns=@JoinColumn("BAR_ID")),
>      ...
> })
> public class MyDatabaseEntity extends MyBean {
>
>      // Nothing in here.
>
> }
>
> Haven't tried it, though.

I guess the question is whether it will work without
@MappedSuperclass on the base class.

Arne

[toc] | [prev] | [next] | [standalone]

#661

Fri, 27 Dec 2013 22:34:36 -0500, /Arne Vajhøj/:
> On 12/25/2013 6:21 AM, Stanimir Stamenkov wrote:
>
>> @Entity
>> @AttributeOverrides({
>>     @AttributeOverride(name="foo", column=@Column("FUN")),
>>     ...
>> })
>> @AssociationOverrides({
>>     @AssociationOverride(name="bar",
>> joinColumns=@JoinColumn("BAR_ID")),
>>     ...
>> })
>> public class MyDatabaseEntity extends MyBean {
>>
>>     // Nothing in here.
>>
>> }
>>
>> Haven't tried it, though.
>
> I guess the question is whether it will work without
> @MappedSuperclass on the base class.

Yes.  I think @MappedSuperclass is only necessary for the framework 
to pick any explicit mappings (JPA annotations) defined on the super 
class, but still – needs to be tested with the JPA implementation in 
use.

-- 
Stanimir

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.databases

csiph-web