Some modifications to fulfill standard development with .NET

[Authfix]

Sound pretty solid.

Some projects are not in the src folder (pull request done on @kbeaugrand fork).

ClientApp folder and wwwroot ? Think we can discuss about that.

[danielpetisme]

@kbeaugrand Thanks for this huge refactoring.... a bit to big in fact. In the same PR, you're proposing

• JHipster.Net core lib namespaces refactoring
• Sample app namespaces refactoring
• OpenId
• ClientApp packaging

It's a kind of blocking PR for other contributors (too much breaking stuff). Could you split the PRs to ease the review and speed up the integration.

Priority1 the namespaces namings and structure, please.

[kbeaugrand]

Hi,

I'll try to do it this week.

Regards,

[danielpetisme]

We definitively needs to split the PR!!

Hey, I had a qiuck overview and I have some concerns:

• JHipsterNet will be externalize as a nuget dependency. I saw you've splitted into 2 projects which means 2 dependencies tomorrow? IMHO, early optimization is evil. The projects are too small to pay the cost of packaging. => Merge JHipsterNet and JHipsterNet.Mvc

• Regarding the components JHipsterNet manages, please follow Jhipster Java split (Problems, Paginationutil, etc are part of this application not the core lib). Centralizing this point make the app more rigid to user modifications.

• DDD is great but 1/introduce a structure complexity for small/medium apps 2/hard to generate (you gather some domain objects into a BankAccount namespace, we can't be determinitic on a business question. Either your build an module-like structure (like angular) or a technical one (data, service, web).

• What's the benefice of the *Entity*Store and *Entity*Manager. So far Queryable looks good enough for a CRUD?

• Why do you include the version into the Mvc namespace ? Usually it's a bad practice to have versionning hard coded in the code (the good practice is to use Headers).

[kbeaugrand]

Hi my answers:

• Merge JHipsterNet and JHipsterNet.Mvc => OK but don't worry about packaging and dependencies in .NET with Nuget ;)
• Could you explain what you're expecting ?
• I love DDD!! Ok for the complexity. But regarding JHipster, I would expect that whe will have to deal with multiple database providers. working with DDD will enable it for us quickly.
• Queryable could be sufficient, but you cannot always rely on the controller part expecially for the last point.
• I'm including version in directory structure since, while working with version (even in headers), we will need different behaviore regarding the api version and some shared behaviors. Working with Managers will help us to keep shared beahaviors and working with different controllers (Same URI, but called differently by the header, or in query parameter), help us to deal with different version of your API working together (expecially with Models).

You can close this PR, I'll do other PR further

Regards,

[danielpetisme]

Ok so I close this one and we move to smaller PRs. The smaller they are, the easier it is to review, the faster they are merged. 🚀 (+ it's not blocking for further PRs, poke @Authfix )

Some guidelines. The jhipster generator can propose options, so try to be propose the simplest default implementation and keep the "flavors" for a more detailed generation. I that point, I don't know if DDD, Store/Manager, are mandatory or correspond to a more "elaborate" base code. As a comparision, JHipster default the generated application use a very straightforward architecture. The repositories are directly used in the controllers and the service layer, dtos, interfaces for services are generation options. https://github.com/jhipster/jhipster-sample-app

Thank your for your motivation!! It's awesome!