What is a good architecture for a Lift-JPA application?
Posted
by egervari
on Stack Overflow
See other posts from Stack Overflow
or by egervari
Published on 2010-06-02T11:37:14Z
Indexed on
2010/06/14
5:22 UTC
Read the original article
Hit count: 218
I was wondering what is the best practice for a JPA model in Lift? I noticed that in the jpa demo application, there is just a Model object that is like a super object that does everything. I don't think this can be the most scalable approach, no?
Is it is wise to still do the DAO pattern in Lift? For example, there's some code that looks a tad bloated and could be simplified across all model objects:
Model.remove(Model.getReference(classOf[Author], someId))
Could be:
AuthorDao.remove(someId)
I'd appreciate any tips for setting up something that will work with the way Lift wants to work and is also easy to organize and maintain. Preferably from someone who has actually used JPA on a medium to large Lift site rather than just postulating what Spring does (we know how to do that) ;)
The first phase of development will be around 30-40 tables, and will eventually get to over 100... we need a scalable, neat approach.
© Stack Overflow or respective owner