I have noticed that Play! Framework encompasses persistence strategy (like JPA etc…)
Why would a web framework care about persistence ?!
Indeed, this would be the job of the server-sides components (like EJB etc…), wouldn’t this?
Otherwise, client would be too coupled with server’s business logic.
UPDATE: One answer would be : it’s more likely used for simple application including itself the whole business logics. However, for large applications with well-designed layers(services, domain, DAO’s etc..), persistence is not recommended within web client layer since there would be several different web(or not) clients.
2
If the framework is used as part of an application that involves a database back-end, then it may be useful to have persistence of the data in a form that doesn’t require the physical database.
For example, I can remember a previous workplace that used Fluent nHibernate as the ORM tool that would be used translate database tables to objects. This would be one example.
Given that Play! is built in Java, it would appear to be a server-side component thus making that 3rd line add little value to the question, IMO.
To elaborate a bit more, I see a few pieces together and this is where persistence plays a role:
- The system has a Web UI component that makes web pages for the user.
- The system has a database component where stuff is stored where various CRUD operations are performed.
- There is the desire to test components independently of each other.
Thus, to test the Web UI component without having the database requires one to construct something to mimic being the database which is what the persistence piece usually is.