Preview:
One way to enforce this rule is to design your API in such a way that it requires users to supply an identifier for a SatelliteData entity rather than the entity itself. This way, the data access layer would be responsible for fetching the correct entity based on its identifier.

This could look something like this:

java
Copy code
public class SatelliteService {

    private final PersistenceLayer persistenceLayer;

    public SatelliteService(PersistenceLayer persistenceLayer) {
        this.persistenceLayer = persistenceLayer;
    }

    public SatelliteDataDTO getSatelliteData(String satelliteId) {
        return persistenceLayer.fetchSatelliteDataById(satelliteId);
    }

    public void updateSatelliteData(String satelliteId, SatelliteDataDTO satelliteData) {
        persistenceLayer.updateSatelliteData(satelliteId, satelliteData);
    }

    // Other service methods...
}
In this way, the SatelliteService is responsible for calling the appropriate methods on the PersistenceLayer and it does not allow clients to supply their own SatelliteData entities. Instead, it requires them to provide an identifier, which it uses to fetch the appropriate entity from the database.

This approach requires that each SatelliteData entity has a unique identifier that can be used to retrieve it from the database. This is a common requirement in many domain models.

This approach not only ensures that entities remain attached to the Hibernate session, but it also encapsulates the data access code in the data access layer, keeping it separate from the rest of your application.
downloadDownload PNG downloadDownload JPEG downloadDownload SVG

Tip: You can change the style, width & colours of the snippet with the inspect tool before clicking Download!

Click to optimize width for Twitter