In my project I have some entity-related methods to make my life easier at some very specific tasks, such as entity sorting using comparators, and child-by-name selection. Normally I would keep this Comparators and Facility-Methods in the same Entity, but CUBA seems to do things differently, and feel wouldn’t be doing things in the proper manner if kept doing that.
So where is the CUBA-way to store Entity comparators and some related methods (that take parameters, for non-parameter methods a transient property works great).
An example would be, take I have a PERSON class and ADRESS class, with 1-N aggregation. Say ADDRESS has a name attribute to identify its type. I would like to have a method to retrieve a Person’s “Home” address for instance:
Person.getAddress(String addressName);
Is it recommendable to keep this method in the Person class? Doesn’t look very orthodox to me. On the other hand, keeping it in a service looks unefficient to me due to back and forth serialization of entities for the sole purpose of retrieving an entity.
Before I help and give my opinion, I would like to get some more facts.
Is it a case where you will be having address types that are not the usual “Home”, “Work”, etc ?
Are the address types basically fixed or static for all persons ?
Will it be okay to use transient attributes such as person.getHomeAddress(), person.getWorkAddress(), etc
or is it that persons may have types of addresses that we are unable to predetermine ?
I wouldn’t bother implementing simple rules that are “owned by the entity” (comparator, “custom getters”, etc) in the Entity class. Sometimes you are “encouraged” to that (@NamePattern annotation). Take a look at getCaption() method of the standard User class.
Depending on your answers to @robert.gilbert questions, you may want to create transient readonly fields.
Just remember to use the @MetaProperty annotation including the needed related fields for the correct usage of these methods with cuba views.
in general, having methods in Entity classes is not only possible but also welcome in order to not end up here: AnemicDomainModel.
You can create any kind of method in the Entity class. The only caveat here is that if you name your method getHomeAddress then due to the java bean specification and all the magic around it CUBA will try to treat it as a “field” homeAddress. So easiest way to avoid that all-together: call your method not get... but instead: public Address homeAddress().
With that you avoid all kinds of strange situations and furthermore the get prefix is somewhat pointless anyways
