Validate Namespace organisation

[danielpetisme]

Currently the namespaces are inspired by the Java packages names of JHipster. The namespace organization and naming should follow the .Net convention and culture.

[kbeaugrand]

Hi Daniel,

I had fork this repository and working on the namespaces from web part.
I'll do a PR as soon as possible.

Regards,

[jdubois]

OSS is awesome, this is so cool that JHipster.NET takes off so quickly.

[danielpetisme]

Local lobbying ;-) Le jeu. 14 févr. 2019 à 20:05, Julien Dubois <notifications@github.com> a écrit :

…

OSS is awesome, this is so cool that JHipster.NET takes off so quickly. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#8 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAkOnH3KboXfbN48pQri_hEQ1VkYxZulks5vNbN-gaJpZM4ax2QO> .

[danielpetisme]

I propose to track the application structure choices here:
The purpose of JHipsterNet is to serve small/Medium applications.
So far, from what I have understood:

• DDD interest is growing in the .Net community but as explained in the ASP.Net Core guidance book DDD is well-suited to large applications with significant business (not just technical) complexity.
• Projects are heavily used .Core, .Infrastructure, .Web like in https://github.com/ardalis/CleanArchitecture/

The points not clear

• Controllers for REST API. In Java, we use a web.rest package and Resources. I understood .Net devs only relies on the Controllers concepts but I found controllers in the Areas, Api and Controllers namespace. Identity managemement, health and logs exposition looks a good candidates for the Areas but I've got a mixed feeling spreading controllers in many folders.
• ViewModels. JHipster Java uses ViewModel to represent data objects only use to interact with the REST API without any data mapping or transformation to domain models (like a json to store a user and password).

@kbeaugrand @Authfix I need your help here!

[Authfix]

In Asp.net core, everything is a Controller. There is no more distinction (via inheritance or attribute) between an "Api" controller or a "Mvc" controller. Today, I try to have a project Api-oriented (without view engine) and/or Mvc-oriented (with view engine) but not both.

By default, namespaces correspond to the Assembly name plus the folder hierarchy.

That said :

• Areas exist to allow isolation of functionalities and are mainly used on large applications with large functional requirements. An area is a MVC structure inside the application. For each area, we find the default MVC folders structure Controllers/Views/Models.
  So, It's not an issue to have many Controllers namespace because each area is an MVC structure like a "sub-application". With it, we can easily add security/rules/routing... etc... to an entire part of the application.
  But, as you said, by default, it multiply folders and namespaces (we can use attributes but i'm not going to explain all mechanisms we can use to deal with areas).

Now, regarding JHipster.NET goals, I think usage of areas will add a complexity that is not necessary, especially in an Api-oriented context with Angular/React clients.

• For ViewModels it's more "opinionated" (I often have this discussion with other developers). For me, ViewModels" are a "Presentation" tool. Unlike DTO which are a "Representation" tool.
  A ViewModel often does the round trip between GET (to create the presentation) and POST/PUT (to return value from the presentation) unlike the DTO who is just a representation of a ressource at a time.

So there is no room in an API-oriented application for ViewModels. But there is a shiny place for ViewModels in an MVC-oriented application (with views like razor pages).

My 2 cts ;)

[danielpetisme]

@Authfix Thanks!
So, to start no Areas and everything is a Controller ✔️
In my first prototype I just mimic the Java jhipster structure view ViewModel.
I would be interested to have @jdubois vision on that point.