Closed danielpetisme closed 5 years ago
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,
OSS is awesome, this is so cool that JHipster.NET takes off so quickly.
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 https://github.com/jhipster/jhipster-net-sample-app-template/issues/8#issuecomment-463751423, or mute the thread https://github.com/notifications/unsubscribe-auth/AAkOnH3KboXfbN48pQri_hEQ1VkYxZulks5vNbN-gaJpZM4ax2QO .
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:
.Core
, .Infrastructure
, .Web
like in https://github.com/ardalis/CleanArchitecture/The points not clear
web.rest
package and Resource
s. I understood .Net devs only relies on the Controller
s 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.@kbeaugrand @Authfix I need your help here!
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.
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 ;)
@Authfix Thanks! So, to start no Areas and everything is a Controller :heavy_check_mark: In my first prototype I just mimic the Java jhipster structure view ViewModel. I would be interested to have @jdubois vision on that point.
Currently the namespaces are inspired by the Java packages names of JHipster. The namespace organization and naming should follow the .Net convention and culture.