package of TOs

[hohwille]

I have already moved the base classes AbstractEto and AbstractCto to general.common.api.to. From a discussion we will also move the concrete Eto and Cto classes to component.common.api.to.

Reason: The Transferobjects of a business component are not specific or explicitly limited or dedicated to the logic layer. There was also a discussion that they would belong to the service layer (out of scope for this ticket). Putting them to common makes sense and allows to use them also in the client layer (e.g. if once somebody wants to write a GWT client based on OASP). If assigned to the logic layer the client layer would not be allowed to use the TOs according to the architecture model.
To document this change, I create this ticket.

[hohwille]

I will also update cobigen templates accordingly.

[hohwille]

I will also change the component Interfaces and Implementations to be compatible with what CobiGen is producing. TableManagement will then be Tablemanagement as the package is also tablemanagement and cobigen can currently not re-apply CamlCase to any string. This will really not hurt and CobiGen will add a feature to address this for those who love perfection.

[maihacke]

Putting the TO (ETOs/DTOs) in common/api looks wrong to me. For me they are part of the logic layer api for the component. They should go to logic/api.

[hohwille]

Putting the TO (ETOs/DTOs) in common/api looks wrong to me.

Surely we can discuss this but actually assigning something to a layer is implicitly limiting the usage and access. We are technically using these objects in the client. If we would have a GWT client, we would violate our own architecture rules if we put the objects in logic. According to simplicity (KISS) we avoided extra service transfer objects. For our sample application we could still move the TOs back to logic but for me they are "common" within the component just like datatypes are.

[maihacke]

After discussion with Jörg we decided to open a ticket for that (see oasp/oasp4j-sample#39).
Main argument is that putting them in common suggests, thats okay to use them in persistence layer. That would be wrong.

[hohwille]

Sorry guyz but sonarqube is now complaining for good reason that we are violating our own architectural rules:
We are accessing logic layer from persistence layer and that is odd.
Reason is exactly the TOs that should be located in common rather than in logic.
Example:
io/oasp/gastronomy/restaurant/offermanagement/dataaccess/impl/dao/ProductDaoImpl must not use io/oasp/gastronomy/restaurant/offermanagement/logic/api/to/ProductFilter

[hohwille]

The same applies for all SearchCriteria TOs that are used by DAOs.
I am back at my original point that we should move all TOs to common package.

[maihacke]

So my argument was exactly that putting TOs to common is wrong, because we don't want them in the persistence layer. If it's permissive to use TOs in persistence I agree they should go to common.

[hohwille]

@maihacke did you study my prior comment? SearchCriteriaTOs are exactly for search criteria used in dynamic queries that belong into DAOs in dataaccess.
So they have to be in common.

Feel free to argue that ETOs should not go to common if you like. This might be a pointless discussion but for SearchCriteriaTO this is IMHO just obvious and no discussion needed.

[hohwille]

@maihacke I saw it comming from the start. If we define an architecture and rules we should strictly follow it. Have a look here (SonarQube now reveals our mistakes):
https://devon-sonarqube.dev.s2-eu.capgemini.com/sonarqube/project/issues?id=io.oasp.application%3Amtsj&open=AWIKDQ-wvBcKeFLsmwWp&resolved=false&rules=devon-java%3ADevonArchitectureLayerDataaccessLogicCheck%2Cdevon-java%3ADevonArchitectureScopeBaseBaseCheck&severities=CRITICAL

So lets change this as I proposed.

[maihacke]

I think there should be SearchCriteria objects in the persistence layer and a mapping from the TOs to the persistence objects in the Uc implementation. This has also the benefit that, if we replace SearchCriteriaTO with Spring-Datas-Implementation, a dependency to spring-data at theservice-layer would occur.