Develop Reference

Persisting nested or related objects for testing created with builder pattern and JPA/Hibernate

Let's take the following classes which are a simplification of more complex classes and their relationships.
#Data
#Builder
public class UserAccount {
private String username;
private String password;
private Language contactLanguage;
public static UserAccount.UserAccountBuilder defaultUserAccount() {
return UserAccount.builder()
.username("default_username")
.password("default_password")
.contactLanguage(defaultLanguage().build());
}
}
#Data
#Builder
public class Language {
private String name;
private String iso2;
private String iso3;
public static Language.LanguageBuilder defaultLanguage() {
return Language.builder()
.name("default_language_name")
.iso2("default_iso2")
.iso3("default_iso3");
}
}
Using Lombok's #Builder annotation, I can easily construct an object like this, especially for testing:
UserAccount.builder()
.username("foo")
.password("bar")
.contactLanguage(Language.builder()
.name("English")
.iso2("EN")
.iso3("ENG")
.build())
.build();
// Or even like this...
defaultUserAccount().build();
This works fine for unit tests or any tests where such generated objects are only required to exist in memory.
However I'd also like to use this approach for integration tests with an underlying database (using Spring Boot 2.4 + JPA + Hibernate). And this is where some issues come up I couldn't solve so far. Let's have a look:
Each UserAccount needs to have a contactLanguage, but Language lives on its own. Other entities might use it as well. When constructing a user account with defaultUserAccount().build(), then persisting this entity fails because the Language object has not been persisted yet. There is no persist cascade on contactLanguage because I don't want "any" Language being created upon creating a UserAccount.
My only idea would be to use defaultLanguage().build() and persist this before defaultUserAccount().build(). But I feel that this will become complex and flaky as soon as there are more levels of nested builders or relationship to other entites.
Another thing is: Even if I managed to persist the defaultLanguge, I would run into a collision as soon as another test calls defaultUserAccount().build() because then the langauge already exists and cannot be inserted again.
Are there any patterns or approaches for persisting such test data objects?
Update #1
After more searching, I found this question on SO which looks almost identical.

Annotations in domain objects with JPA violates Database is a detail

What do you think about have persistence models and domain models separated? I've read that you don't have to mix persistence concerns with your business concerns (DDD, Clean Architecture,MartinFowler, Eric Evans and a lot and a lot of much more). Even so, I still see in all projects domain models annotated directly with ORM annotations like that, being the domain model coupled to the persistence mechanism reaching an anemic model and violating other principles.
//PersistenceJPA entity
#Entity
#Table(name="training_cycle")
class TrainingCycle {
#Id
private Long id;
private String name;
#Column(name="discipline_id")
#JoinColumn(name="discipline_id")
private Long disciplineId; //Referencing by Id because Discipline is another Aggregate ROOT
//EmptyConstructor, getters and setters avoided
}
//PersistenceJPA entity
#Entity
#Table(name="training_cycle")
class Discipline {
#Id
private Long disciplineId;
private String name;
//EmptyConstructor, getters and setters avoided
}
So if you want to follow clean principles you need to split Domain and Persistence Model(as shown below)to have Domain model with business behavior(this avoid anemic model and follows the SRP) and because of that you need to map the domain model to the persistence model (with typical methods like mapToEntity(DomainModel DM) and mapToDomain(PersistenceModel PM) maybe in a mapper/tranformer maybe in the repository class) when you want to interact with Datastore and viceversa when you want to retrieve data from database.
class Discipline {
private DisciplineId disciplineId;
private String name;
public Discipline(DisciplineId disciplineId, String name) {
this.disciplineId = disciplineId;
this.name = name
}
}
public class TrainingCycle{
private TrainingCycleId trainingCycleId;
private String name;
private DisciplineId disciplineId;
public TrainingCycle(TrainingCyleId trainingCycleId, String name, DisciplineId disciplineId) {
this.trainingCycleId = trainingCycleId;
this.name = name;
assignDiscipline(disciplineId);
}
public void assignDiscipline(DisciplineId aDisicplineId) {
if(aDisicplineId == null) {
throw new IllegalArgumenException("Discipline cannot be null")
}
this.disciplineId = aDisicplineId;
}
}
#Entity
#Table(name="training_cycle")
class TrainingCycleJpa {
#Id
private Long id;
private String name;
#Column(name="discipline_id")
#JoinColumn(name="discipline_id")
private Long disciplineId; //Referencing by Id because Discipline is another Aggregate ROOT
//EmptyConstructor, getters and setters avoided
}
#Entity
#Table(name="training_cycle")
class DisciplineJpa {
#Id
private Long disciplineId;
private String name;
//EmptyConstructor, getters and setters avoided
}
class TrainingCyleJpaRepository implements TrainigCycleRepository {
public void create(TrainingCycle trainingCycle) {
entityManager.persist(this.mapToEntity(trainingCycle)
}
public TrainingCycle create(TrainingCycleId trainingCycleId) {
return this.mapToDomain(entityManager.find(TrainingCycleId));
}
}
So the discussion/question is Split or not Split Persistence Model from Domain Model? When to split or when not? In the most projects, not to say in all the ones I've seen as an example, I've seen they couple annotations of persistence model in Domain Model when "gurus are allways hawking" DataStore is a detail.
Thanks a lot.

Please check out this very similar question: Are persistence annotations in domain objects a bad practice?
I think that as engineers we should be pragmatic. Any best practices, principles, or "guru suggestions" should help. They should not make things worse. So I suggest to treat them as guidance, not strict rules. For instance, I generally agree that "database is a detail". But we rarely change that detail.
On the other hand, annotations do not execute any code. And the coupling is not so bad. Your domain object can be a JPA entity at the same time, and it will be very clean and useful. By the way, this does not violate the Single Responsibility Principle (SPR). If you thought it does, check out SOLID explanation by its author Uncle Bob
EDIT
#RenéLink I don't agree: Annotations are interpreted and the code that executes them can be exchanged with a different interpreter even with a no-op interpreter. The annotation stays untouched and doesn't care. It's a declarative element, nothing more.
Annotations are source code dependencies, which means that the source code can not be compiled if the annotation is not present on the compile classpath.
It's right that annotations are not hard runtime dependencies. If the annotation class is not available on the classpath the annotation is also not available. Thus you can use bytecode that was compiled with annotations even if the annotations are not present on the classpath.
So annotations are a less restrictive dependency then normal classes, interfaces and so on.
I always try to minimize the dependencies in my code. Let's take a spring example.
In spring you can either implement InitializingBean or you can define a method annotated with #PostConstruct in this case I would use post construct. Often I don't need a #PostConstruct, because I do constructor injection. But if I move the initialization to a java config I can just call an arbitrary 'post construct' method befor returning the bean instance and I don't need a #PostConstruct annotation at all.
I agree that annotation dependencies are less problematic than other classes or interfaces. But keep in mind that the annotations the OP talks about also have another problem. If you mix domain objects with JPA annotations you violate the single responsibility principle. Your domain objects now have more then one reason to change (domain changes and persistence changes).
You will recognize the problem as soon as you add #Transient annotations or you might get merge conflicts because you changed domain logic and a colleague persistence things.

Yes, these annotations are details and should be kept away from the entities of the clean architecture.
Don't be confused about the name entity in the clean architecture and the #Entity annotation from your persistence framework. They are different things.
There is a video of Uncle Bob about clean architecture and at the end he makes it really clear, because he says:
the entities are not instances of database tables. They are usually constructions from many database tables.
In another video he talks about dependency injection and the annotations that these frameworks use. Well, dependency injection has nothing to do with persistence that you asked for, but this video makes clear what Uncle Bob thinks about framework annotations in the use case or entities layer of the clean architechture.
And in this video he makes it really clear that the entities should not have persistence details. It doesn't matter if it is hibernate or JPA.

Validation through "mixins"

I am developing a RESTful API in Spring Boot 2+, for which I need to perform several validations. Nothing really fancy, just the typical #NotNull, #NotEmpty, #Max, #Min, #Email, #Regex, #Future, etc stuff...
Except that I have beans from an API that I must use yet cannot modify. This means that I cannot annotate the fields and methods in those DTOs.
It would be great if I could create mixin-like classes or interfaces with the same structure of the real DTOs I must use in the API, on which I would happily place bean-validation's annotations.
For example, if I had the following DTOs that I couldn't modify:
public class Person {
private String name;
private String dateOfBirth;
private Address address;
// constructors, getters and setters ommited
}
public class Address {
private String street;
private String number;
private String zipCode;
// constructors, getters and setters ommited
}
I would create the following 2 interfaces that mimic their structure and annotate them as I need:
public interface PersonMixin {
#NotBlank String name();
#Past String dateOfBirth();
#Valid #NotNull Address address();
}
public interface AddressMixin {
#NotBlank String street();
#Positive int number();
#NotBlank String zipCode(); // Or maybe a custom validator
}
As you see, the name of the methods in the interfaces match the names of the properties of the bean classes. This is just one possible convention...
Then, ideally, somewhere while the app is loading (typically some #Configuration bean) I would be very happy to do something along the lines of:
ValidationMixinsSetup.addMixinFor(Person.class, PersonMixin.class);
ValidationMixinsSetup.addMixinFor(Address.class, AddressMixin.class);
Except that ValidationMixinsSetup.addMixinFor is pure fantasy, i.e. it doesn't exist.
I know that there exists a similar construct for Jackson regarding JSON serialization/deserialization. I've found it extremely useful many times.
Now, I've been looking at both Spring and Hibernate Validator's source code. But it's not a piece of cake... I've dug into ValidatorFactory, LocalValidatorFactoryBean, TraversableResolver implementations, but I haven't been able to even start a proof-of-concept. Could anyone shed some light into this? I.e. not how to implement the whole functionality, but just how and where to start. I'm after some hints regarding which are the essential classes or interfaces to extend and/or implement, which methods to override, etc.
EDIT 1: Maybe this approach is not the best one. If you think there's a better approach please let me know.
EDIT 2: As to this approach being overly complicated, too convoluted, Rube Goldberg, etc, I appreciate and respect these points of view, but I'm not asking whether validation through mixins is good or bad, convenient or inconvenient, neither why it might be like so. Validation through mixins has pros on its own and I think it could be a good approach for some valid use cases, i.e. having declarative validation instead of scripted or programmatic validation while also separating validation from the model, letting the underlying framework do the actual validation job while I only specify the constraints, etc.

Using programmatic API (as mentioned in the comment) in case of Person you could apply next mappings for your constraints:
HibernateValidatorConfiguration config = Validation.byProvider( HibernateValidator.class ).configure();
ConstraintMapping mapping = config.createConstraintMapping();
mapping.type( Person.class )
.field( "name" )
.constraint( new NotNullDef() )
.field( "number" )
.constraint( new PositiveDef() )
.field( "address" )
.constraint( new NotNullDef() )
.valid();
Validator validator = config.addMapping( mapping )
.buildValidatorFactory()
.getValidator();
And as you are using Spring - you would need to do that in one of your sping config files where you define a validator bean.

How can I achieve bean validation in Java SE 1.6

The project which I work is a simple Java SE program which is ran using public static void main method. I have a DTO bean called StudentBean:
class StudentBean {
private String firstname;
private String lastname;
private Integer id;
private Integer age;
//setters and getters
}
I have over 100k student beans stored in a java.util.ArrayList. We have set of rules for each field. For ex, firstname should not be null and empty, age cannot be negative.
How do I write java code for validating hundreds of thousands of beans against the rules we have and write the log for the beans which violates the rules?
We thought of writing custom annotations like #NotNull, #NotEmpty, #PositiveNumber and have a validator logic which validates the beans according to the annotations they have on their variables. If you find this good, please point me to online resources which I can use to implement this.
As this is Java SE project, we do not have javax.validation jar, so no scope of using this library. It would be very helpful if we can achieve it using Java SE library only.

You can have a look at hibernate validator, and how to bootstrap the validation. There are already constraints you need available out of the box.
The fact that this is Java SE project doesn't mean you can't bootstrap validation by yourself.

I would try to keep it simple and just use a method public boolean isValid () within the bean which implement your rules. This way you need no annotations and no reflection.

Adding property values to Spring beans at runtime

It might be a very simple question; but since I am a beginner into Spring, I cannot understand how to assign values to Spring beans at the run time.
I followed some tutorials for learning Spring and now I know how to get started with Spring. I can understand the Spring beans.xml where the bean definition is declared, I can understand some annotations which can be used instead of xml configurations. But I cannot understand how to do the following configuration.
Let's say I have a class called Student. Each student object has a name and an age.
public class Student {
private String name;
private int age;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public int getAge() {
return age;
}
public void setAge(int age) {
this.address = address;
}
}
This is how will I write the entry in the Beans.xml file for bean configuration
<bean id="student" class="Student">
<property name="name" value="Joe"></property>
<property name="address" value="12"></property>
</bean>
I am completely okay with this setter injection. As far as I can change the property values using the xml file,I can change the properties of the student.
But let's think we need an application to register students. Using front end form of the application, we enter name and age. My question is how can we inject those name and age values to a Student bean. Now we are dealing with a running application.
I can't understand how should we change the xml to accept the user inputs(if it is the way of doing). In all the beginner tutorials I followed, I didn't find a way to handle such situations. What they teach is what I already know.
I think I am missing some lesson on this. Please guide me to solve my problem. Some example code will be much helpful for me to understand if possible.
Thank You..!

You dont find any tutorial for your problem because your usecase is not sutable for spring. In practice we dont use spring to achieve what you are trying to do. Spring is best suitable for dependency injection of classes with singleton behaviour for example service classes for which you will generally need single instance across your application.
Generally we use ORM like hibernate for the use case which you are ferering to.

Beans are not suitable for Value Objects, which is why your approach is not working.
Beans are instantiated classes that will have long running lives during the execution of your program, they are managed by Spring. This includes instances of classes that provides business logic or classes that provide program functionality, like database connections or a socket server.
Value Objects are short lived data object instances that is used by your application, which the student class seems to be. They are managed by your program code.