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

Filed under:
|
|
|
|

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

Related posts about design

Related posts about architecture