Generator-jhipster: v7 - remove non DTO configuration

[Tcharl]

Overview of the feature request

Generating entities without DTO sometimes lead to some mistakes (lazyloading exception and so on).
There was a discussion on the mailing list removing the option.

Motivation for or Use Case

Simplify the generator.
Start the discussion.

Related issues or PR

10958

• [x] Checking this box is mandatory (this is just to show you read everything)

[avdev4j]

hi @Tcharl
does this mean we would always generate the service layer?

[MathieuAA]

Yes @avdev4j. Unless a service option is chosen, the serviceClass option will be used.

[MathieuAA]

Is it sill something we wanna do for v7?

[pascalgrimaud]

I afraid it will be a lot of work... for giving less choice to the user

1st suggestion

Remove:

• No, the REST controller should use the repository directly

And keep only:

• Yes, generate a separate service class -> removed
• Yes, generate a separate service interface and implementation

with DTO as mandatory

2nd suggestion

Keep:

• No, the REST controller should use the repository directly
• Yes, generate a separate service class -> removed
• Yes, generate a separate service interface and implementation

If service class or service interface is choosen, make DTO as mandatory

[MathieuAA]

This is how the JDL parsing system does it: if the dto or filter options are present, it will also add the service (with a class) option

So this issue is like the the other side of the same coin: "merging" dto and service (and filtering).
JDL-wise, this can easily be done, but it should also be implemented in the generator so as to avoid issues like "the JDL and the generator don't generate the same things"...

If there's something we still wanna do but there's nobody available to do it, then we shouldn't tag it as a a goal for v7. Let's remove the tag (and/or close this issue).

[pascalgrimaud]

Agree, so let's remove this for v7
@Tcharl : don't hesitate to comment if you disagree :)

[mshima]

If there is no objections I will create a PR to force dto and service options.
Non dto and non service implementations could be removed during jhipster 7 cycle.
cc @jhipster/developers.

[pascalgrimaud]

@mshima : what do you mean by forcing dto and service options ? will it be by default ?

[mshima]

@pascalgrimaud I though we should remove non-dto option.
For every dto entity test, we must have another entity test without dto to keep both with same level of stability. Same for service.
IMO we should go for it.

Otherwise, to simplify our tests would be to add workflows exclusive to dto/non-dto.
Instead of having EntityTest/EntityDTOTest, we should force dto with jhipster --dto and split workflows into default and default-non-dto.

[pascalgrimaud]

Ok, if I understand well:

? Do you want to use separate service class for your business logic?
❯ No, the REST controller should use the repository directly
Yes, generate a separate service class
Yes, generate a separate service interface and implementation

Rest controller:

This question is unchanged:

No, the REST controller should use the repository directly : no DTO

For Service and Service Interface

Yes, generate a separate service class
Yes, generate a separate service interface and implementation

We'll remove this question and always use DTO:

? Do you want to use a Data Transfer Object (DTO)? (Use arrow keys)
❯ No, use the entity directly 
  Yes, generate a DTO with MapStruct

Can you confirm ?
Or did you suggest to remove the answer REST controller with repository directly ?

[mshima]

Your 1st suggestions.

1st suggestion

Remove:

• No, the REST controller should use the repository directly

And keep only:

• Yes, generate a separate service class -> removed
• Yes, generate a separate service interface and implementation

with DTO as mandatory

Or did you suggest to remove the answer REST controller with repository directly ?

Remove too.

The generator:

• Force every entity with mapstruct dto option and with serviceClass or serviceImpl service option.
  This would prevent from generating entities without dto and service.
• Update prompts.

Templates

• Remove no dto and no service templates during jhipster 7 cycle, this won't be a breaking change.

[pascalgrimaud]

I'm in favor of making DTO mandatory.
In real project, we should never use rest controller with repository directly
But maybe we need to discuss with the team before ? with a mail to the mailing list ?

[jdubois]

Hey, I'm not using any DTOs most of the time! I know what everybody says, but for simple stuff that works really well, and you have better performance. I believe it's the same thing with Ruby on Rails, by default (and for very simple apps) they have no DTOs.

[mshima]

@jdubois thanks.
So let's rule out dropping non-dto.

As we continue integrating relationships sides, such as composite id, mixing dto with crud becomes more problematic.
In this case we could:

• keep as a warning, the user should deal with it.
• make dto a global preference.
• force dto when a relationship with dto is found.

[jdubois]

Also, MapStruct might be a little bit complicated for new developers. I'm the one who choose it and I love it, but for newcomers that's more complicated than just coding directly. We should have great Developer Experience for new people.

[pascalgrimaud]

Fine with this, @mshima

[mshima]

Closing, the proposal about making dto a global option and what approach to follow should be discussed at another issue.
For now we are at keep as a warning, the user should deal with it. approach.