Say I want to populate a JPA entity using values supplied by a user through a web application form (Tapestry for that matter).
What is the best way to obtain the "blank" instance of the JPA entity that is going to be bound to the form fields?
As of now I just use the new operator as follows in my Tapestry class:
childminderAccount = new ChildminderAccount();
Is this not a somewhat a crude way of doing it? Is there a better way?
Nope, that's the best way to do it. One of the advantages of JPA (over old EJB Persistence) is that it is a "lighter" framework. One of it's lightnesses is the fact that it now works woth POJOs (or Java Beans). I would recommend however to take a look at Java's new validation API which is very lightweight as well, and it can insure that a JPA Bean is correctly populated from your form (like no non-nullable fields set to null, empty id field etc):
http://www.hibernate.org/subprojects/validator.html
Related
In my Spring MVC application we have form objects that are mapped to by the <form:form tag in JSP. These objects are separate from my regular model beans, and really form a sort of view model. The difficulty with these objects is the mapping between these objects and the actual model beans expected by the service objects. Currently we have manually written code mapping forms to beans and vice versa in the controllers. This is less than optimal because of the amount of extra code it requires. The other options we've considered are.
Write a mapping class. This still requires manually writing the code, but at least it's not in the controller.
Automatically generate the mapping class. Presumably this would require manually generating and updating some sort of mapping file.
Name the properties in beans and the forms the same and use Spring's BeanUtils.copyProperties to move them back and forth. This seems bad because it is not an obvious link would cause strange run-time behavior if it wasn't kept consistent.
Write the form object as a facade that keeps a bean internally and updates it.
What is the best method for the long term health of the project of performing this action?
I suggest you to use dozer framework for mapping domain objects and view object to each others .Only problem you will have to still create view class manually.You can also automate this with code generation.
I was looking over the DynatableRF example and I was wondering why in SummaryWidget when you create a new Person instance the subfields like address and schedule are not auto-populated. Is there a better way than to manually instantiate a new instance of every non-primitive subfield down the tree?
The framework can't auto-populate subfields because it won't know if you want instances in those fields or you want them to be null. You want different things in different circumstances.
It sounds like what you are asking for is Dependency Injection in which case the GIN (GWT INjection) project can help.
I am using Spring Data JPA in an application in which all entity objects need auditing. I know that I can have each either implement Auditable or extend AbstractAuditable, but my problem is coming with the overall auditing implementation.
The example on the Spring Data JPA reference pages seems to indicate that you need an AuditableAware bean for each entity. Is there any way to avoid this extra code and handle it in one place or through one configuration?
The generic parameter of AuditorAware is not the entity you want to capture the auditing information for but rather the creating/modifying one. So it will typically be the user currently logged in or the like.
I was wondering what the general recommendation is for Entity Framework in terms of data validation. I am relatively new to EF, but it appears there are two main approaches to data validation.
The first is to create a partial class for the model, and then perform data validations and update a collection of rule violations. This is outlined at http://msdn.microsoft.com/en-us/library/cc716747.aspx
The other is to use data annotations and then have the annotations perform data validation. Scott Guthrie explains this on his blog at http://weblogs.asp.net/scottgu/archive/2010/01/15/asp-net-mvc-2-model-validation.aspx.
I was wondering what the benefits are of one over the other. It seems the data annotations would be the preferred mechanism, especially as you move to RIA Services, but I want to ensure I am not missing something. Of course, nothing precludes using both of them together.
Thanks
John
I have been using DataAnnotations using MVC 2 and it works great. I have not tried the partial on an entity object for validation, but I see its uses. Basically if I create a partial class on an entity object I use it to default data such as a GUID identifier. or Create Date or modified Date. I guess it would be useful to add validations in the partial class perhaps for some complex validation that needs to happen in the entity layer but even then those validations could be accomplished in custom validator. If you are using an MVC website then I would personally use dataannotations.
I'm using DataNucleus as a JPA implementation to store my classes in my web application. I use a set of converters which all have toDTO() and fromDTO().
My issue is, that I want to avoid the whole DB being sent over the wire:
If I lazy load, the converter will try to access ALL the fields, and load then (resulting in very eager loading).
If I don't lazy load, I'll get a huge part of the DB, since user contains groups, and groups contains users, and so on.
Is there a way to explicitly load some fields and leave the others as NULL in my loaded class?
I've tried the DataNucleus docs with no luck.
Your DTOs are probably too fine-grained. i.e. dont plan to have a DTO per JPA entity. If you have to use DTOs then make them more coarse grained and construct them manually.
Recently we have had the whole "to DTO or not to DTO, that is the question" discussion AGAIN. The requirement for them (especially in the context of a JPA app) is often no longer there, but one of the arguments FOR DTOs tends to be that the view has coarser data requirements.
To only load the data you really require, you would need to use a custom select clause containing only these elements that you are about to use for your DTOs. I know how painful this is, especially when it involves joins, which is why I created Blaze-Persistence Entity Views which will take care of making the query efficient.
You define your DTO as an interface with mappings to the entity, using the attribute name as default mapping, this looks very simple and a lot like a subset of an entity, though it doesn't have to. You can use any JPQL expression as mapping for your DTO attributes.