Isn't there a better approach to building similar applications?
I am working on a mid-sized project (150k LoC), with a similar setup:
- Spring 4
- OpenJPA for persistence
- jQuery as the only frontend "framework". I introduced Backbone.JS which is only halfheartedly adopted. A good deal of our application is grid over data, which is implemented via datatables.net.
We are facing similar problems.
In general, there is only little to no help for that.
If you are using ORM, you have to use the
If you do not want to expose these objects to the outside, there aren't many options:
1) As you already do: use
DTOs - but there is the disadvantage of mapping fields and keeping fields in sync
2) Instantiate a new Domainobject - as said above:
@Entities are POJOs and copy over those fields, you want to expose.
Some of our application is grid over data, so there isn't always the need for fully fledged domain objects and sometimes you need a bunch of attributes from several objects. For such cases there is the possibility to work with
Constructor expressions in the SELECT clause (see specification). So you could build aggregate-objects (or however you want to name these
DTOs) which could span across multiple tables and where each attribute is associated to one column of your resultset. In this case the
new object isn't necessarily an
@Entity. It has to provide only a constructor which takes all of the columns. (Note to myself: try this out for
add to model -> DTO converter (when it's a field that can't be automatically mapped) regarding different scenarios that requires different amount of information about model
This would be best solved via reflection: copy over all fields in the new object from the old one. Done.
The following is highly subjective:
I find ORM isn't the perfect fit for our project. It is a nice to have which frees you from writing tedious boilerplate code, but comes with several downsides: performance trouble (objects involve multiple _LEFT JOIN_s, which you wouldn't need nor make, when writing SQL), too much overhead for simple queries (you get full objects restored instead of just 2 columns or so needed), problems with joins (you are only allowed to join tables, which reflect your models - otherwise, you have to use tricks to get around). If I would start over, I would take a mixed approach: ORM for simple stuff and doing complex stuff with JDBC-templates (our project is currently 100% ORM-Driven).
That said, we now have to take a look at the frontend:
Since the advent of MV*-frameworks on the client-side, the question rises, where to put the stress on: client-side vs server-side validation or using both. Here is a nice talk from yeahuda Katz about »the tale of the two MVCs«.
If you go the client-side road, you haven't a duplication of "models", you have client-side-models and "persistence-objects" (
To sum it up:
- some painpoints stay: add to DB tables, add to model object, (add to DTO), add to Extjs model
- some could be made easy: add to model -> DTO converte (use reflection)
- you could decide on an either-or-base for some: add to client and server validators
Modern applications are complex.