I forum Ricerca FAQ
Fai una domanda
Ultimo messaggio 1 2
jjlotus
jjlotus
il 16 gennaio 2019 alle 16:00
44 messaggi dal 20 maggio 2003
MVC oppure RazorPage
Ciao a tutti, avrei bisogno di un chiarimento/consiglio sulla scelta del modello da utilizzare.
Devo creare una applicazione web per fornire alcuni servizi a clienti.
L'applicazione comunica con il back-end attraverso chiamate rest (java) già presenti.
Sono indeciso se utilizzare MVC oppure RazorPage.
L'applicazione è destinata a crescere molto e dovrà essere facilmente mantenibile.
Qual'è il criterio corretto per optare su MVC piuttosto che su RazorPage?
Grazie
Daniele
RispondiQuoting
BrightSoul
BrightSoul
il 17 gennaio 2019 alle 19:50
11.886 messaggi dal 09 febbraio 2002
Contributi
Ciao Daniele, non ho capito bene se tu devi realizzare solo il frontend o anche il backend.


L'applicazione comunica con il back-end attraverso chiamate rest (java) già presenti.

JavaScript intendi? Se il backend è una REST API già esistente, allora il frontend può essere formato solo di comuni pagine HTML e non è strettamente necessario usare né MVC né Razor Pages.


Qual'è il criterio corretto per optare su MVC piuttosto che su RazorPage?

Puoi scegliere tu liberamente. In ASP.NET Core sono molto simili tra loro e sono equivalenti, dato che si basano sullo stesso identico stack tecnologico.
La differenza è semplicemente nel modo in cui sono organizzati i file nel progetto:
  • Con MVC, i file sono organizzati per responsabilità: le view dentro /Views, i controller dentro /Controllers e le classi del model dentro /Models (o altrove);
  • Con Razor Pages, i file sono organizzati per "obiettivo": se devi realizzare un catalogo, ti crei una directory /Pages/Catalog e al suo interno metti sia la view che il suo "code file" che fa le veci del controller. In sostanza, Razor Pages tende a tenere vicini i file che userai per raggiungere l'obiettivo, cioè realizzare il catalogo.


ciao,
Moreno
Enjoy learning and just keep making
RispondiQuoting
jjlotus
jjlotus
il 23 gennaio 2019 alle 11:51
44 messaggi dal 20 maggio 2003
Ciao e grazie infinite per la risposta.
Il back-end è già esistente ed è fatto in JAVA (J2EE). Ho a disposizione tutte le chiamate REST per recuperare i dati e aggiornare il database.
Lo sviluppo ASP.NET Core è solo front-end, quindi immagino una serie pagine (che nel tempo andranno a crescere molto) che recuperano i dati invocando i servizi REST messi a disposizione e forniscono griglie (con dati modificabili), grafici, informazioni.
La scelta dovrà per forza essere MVC o RAZOR Page e quindi chiedevo qualche consiglio.
A volte leggo che se l'applicazione rimane medio piccola, meglio MVC, altrimenti meglio RAZOR Page.
Già la tua risposta chiarisce molto.
Grazie ancora,
Daniele
RispondiQuoting
BrightSoul
BrightSoul
il 23 gennaio 2019 alle 16:21
11.886 messaggi dal 09 febbraio 2002
Contributi
Ciao Daniele, prego.


Lo sviluppo ASP.NET Core è solo front-end

Tu farai le chiamate alla Rest API Java usando codice C# oppure codice JavaScript?


A volte leggo che se l'applicazione rimane medio piccola, meglio MVC, altrimenti meglio RAZOR Page.

Hai un link a un articolo in cui si parla di questa cosa? Me lo leggo volentieri perché vorrei farmi un'idea su cosa preferiscono gli sviluppatori tra le due tecnologie.

ciao,
Moreno
Enjoy learning and just keep making
RispondiQuoting
jjlotus
jjlotus
il 23 gennaio 2019 alle 16:37
44 messaggi dal 20 maggio 2003
Le chiamate alla Rest API le farò utilizzando esclusivamente C#.
L'articolo l'avevo letto parecchie settimane fa e faccio fatica a ritrovarlo. In ogni caso sottolineava che MVC cresce velocemente perché ogni pagina diventa poi 3 pagine e quindi ci si trova ad avere in poco tempo tantissimi file.
Mentre con RazorPage (essendo + simile alla classica programmazione net file+codebehind) l'applicazione rimane più contenuta e quindi più facilmente mantenibile.
Questo è il concetto che mi ricordo.

Aggiungo anche che il template sarà: http://webapplayers.com/inspinia_admin-v2.9.1/graph_chartjs.html.
L'applicazione è un cruscotto e avrà parecchi indicatori.
Credo verrà progettata a componenti ognuno autonomo nel caricamento.
Modificato da jjlotus il 23 gennaio 2019 17.17 -
RispondiQuoting
BrightSoul
BrightSoul
il 23 gennaio 2019 alle 18:28
11.886 messaggi dal 09 febbraio 2002
Contributi
Ok, ti ringrazio per le info.

Per curiosità: dato che si tratta di un backoffice, perché ha scelto di usare MVC/Razor pages anziché fare una Single Page Application con Angular/VueJS, che invoca ASP.NET WebAPI (o direttamente le Rest API Java)?

Non che usare MVC o Razor Pages sia una soluzione meno valida, eh. Mi interessa il tuo punto di vista dato che oggi sembra che le SPA vadano per la maggiore (ma non ho dati alla mano).
Modificato da BrightSoul il 23 gennaio 2019 18.31 -
Enjoy learning and just keep making
RispondiQuoting
jjlotus
jjlotus
il 23 gennaio 2019 alle 21:41
44 messaggi dal 20 maggio 2003
Tutte le altre applicazioni che sfruttano il medesimo back-end sono infatti fatte in Angular e invocano i servizi in typescript appunto come da te suggerito e intuito.
Ti confermo che la scelta principale dell'azienda sarebbe stata la SPA in Angular, ma questa volta si voleva affidare lo sviluppo a un team NET e quindi si cercava di agevolarli.
RispondiQuoting
BrightSoul
BrightSoul
il 24 gennaio 2019 alle 14:10
11.886 messaggi dal 09 febbraio 2002
Contributi
Ok, grazie, ho capito la situazione.

Se la REST API Java è documentata con Swagger, il team .NET potrà usare questo strumento per costruire velocemente le classi in cui verrà deserializzato il json.
https://github.com/RSuter/NSwag

E inoltre gli potrà tornare utile Refit per interagire con le operazioni esposte dalla API in maniera fortemente tipizzata.
http://www.aspitalia.com/script/1296/Costruire-Client-HTTP-Tipizzato-Refit-IHttpClientFactory-ASP.NET-Core-2.1.aspx

ciao,
Moreno
Enjoy learning and just keep making
RispondiQuoting
1 2

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.