Package com.devonfw.module.basic.common.api.to

Class AbstractEto

  • All Implemented Interfaces:
    GenericEntity<Long>, Serializable
    Direct Known Subclasses:
    RevisionedEto
    public abstract class AbstractEto
extends AbstractTo
implements GenericEntity<Long>
    This is the abstract base class for an transfer-object that contains all the data properties of an entity without its relations. This is called ETO (entity transfer object). Sometimes in other contexts people also call this DTO (data transfer object).
    Here, data properties are the properties using a datatype (immutable value type such as String, Number, Instant, custom-datatype, etc.). Relations of an @link GenericEntity entity} are not contained except for IDs of OneToOne relations. Instead of using Long we recommend to use IdRef to be type-safe and more expressive. For actual relations you will use CTOs to express what set of entities to transfer, load, save, update, etc. without redundancies.
    Classes extending this class should carry the suffix Eto.
    Since:
    3.0.0
    See Also:
    Serialized Form

    • Field Detail

      • id

        private Long id

      • modificationCounter

        private int modificationCounter

    • Constructor Detail

      • AbstractEto

        public AbstractEto()
        The constructor.

    • Method Detail

      • getId

        public Long getId()
        Specified by:
        getId in interface GenericEntity<Long>
        Returns:
        the primary key (unique identifier) of this entity. May be null if this entity is transient (not yet saved in the database). While this method is initially defined in a generic way, it is strongly recommended to use Long as datatype for IDs.
        Even if you want to have a String-based business-oriented identifier it is best practice to use a Long as primary key and add the business identifier as additional field (with a unique constraint). This way references to the entity will be a lot more compact and improve your performance in JOINs or the like. However, there may be reasons to use other datatypes for the ID. In any case the unique ID should be an immutable java-object that can be rebuild from its string-representation.
        Please note that if your ID has a specific syntax, semantic, formatting rules, etc. you should create a custom datatype for it. If it can easily be mapped to a Long value you can still use Long here and provide a transient getter method that returns the your custom datatype from the Long.
        See Also:
        Id

      • setId

        public void setId​(Long id)
        Specified by:
        setId in interface GenericEntity<Long>
        Parameters:
        id - the new primary key. This method shall typically only be used by technical frameworks such as hibernate.

      • getModificationCounter

        public int getModificationCounter()
        Description copied from interface: GenericEntity
        This method gets the current modification-counter of this entity. Whenever the object gets modified and persisted, this counter will be increased (typically after the transaction is closed). The initial value after construction is 0.
        This property is often simply called version. However, as this sometimes causes confusion or may conflict with a business property "version", we use the more technical and self-explanatory name modificationCounter.
        If this feature is NOT supported for some reason, this method should always return 0.
        Specified by:
        getModificationCounter in interface GenericEntity<Long>
        Returns:
        the current modification-counter.
        See Also:
        Version, Version