18 messaggi dal 06 settembre 2002
Sviluppo in ASP.NET WebForms e sto incominciando lo studio di ASP.NET Core.
L'obiettivo e' quello di organizzare una futura migrazione delle mie applicazioni webforms in questa nuova piattaforma.

Le cose che ho sempre apprezzato in ASP.NET Webforms sono state la rapidita' nello sviluppo e la semplicita' dell'architettura (ossia facilita' di manutenzione).

Ho acquistato il libro ASP.NET Core 2 che sto leggendo con molto interesse. Complimenti e' fatto molto bene.

Se posso fare una critica al libro, anche se viene detto all'inizio, e' di non aver dedicato qualche capitolo alle Razor Pages che secondo me sono una valida alternativa al modello MVC.

Per me, che vengo dalle webforms, trovo MVC un modello eccessivamente complesso.
Penso di adottare il modello delle Razor Pages che mi sembra avere gli stessi vantaggi delle webforms: rapidita' di sviluppo e architettura piu' semplice.

Nell'ottica di un passaggio da ASP.NET a ASP.NET Core vorrei sapere qual'e' il modo migliore di riutilizzare, se possibile, queste due funzionalita' di ASP.NET:

- pagine .ashx: le uso spesso per eseguire delle funzioni che non richiedono una view. Ad esempio per il download di un file pdf generato lato server o il download di un file json.

- librerie DLL .NET 4.0: le uso spesso inserendole nella cartella \bin per condividere codice tra le pagine dell'applicazione web.

Grazie per la disponibilita'
salvo
11.097 messaggi dal 09 febbraio 2002
Contributi
Ciao Salvo, e grazie per aver acquistato il libro.


Per me, che vengo dalle webforms, trovo MVC un modello eccessivamente complesso.

Questo sembra essere un tema ricorrente e man mano che andiamo avanti con gli anni saranno sempre di più le persone che vorranno migrare la loro applicazione ASP.NET "tradizionale" ad ASP.NET Core.
Puoi spiegare più nel dettaglio quali sono state le difficoltà che hai incontrato con MVC?
Secondo te è un pattern obiettivamente difficile da comprendere oppure sei riuscito a capire bene come funziona, magari anche grazie al libro, ma per tua preferenza personale preferisci non usarlo perché pensi che sia inutilmente complicato?

Ti faccio queste domande per capire come approcciarmi agli utenti che come te vogliono passare da ASP.NET a ASP.NET Core.

Veniamo alla tua domanda:
pagine .ashx: le uso spesso per eseguire delle funzioni che non richiedono una view. Ad esempio per il download di un file pdf generato lato server o il download di un file json.


Puoi restituire un file all'utente usando un Controller di ASP.NET Core MVC. Infatti, l'action di un controller non è obbligata a restituire una view ma può anche restituire il contenuto binario di un file oppure del contenuto json. In questo caso, nell'action, anziché fare return View() fai return File("percorso") oppure return(oggetto) per fare in modo che l'oggetto in questione ti venga serializzato automaticamente come json.

- librerie DLL .NET 4.0: le uso spesso inserendole nella cartella \bin per condividere codice tra le pagine dell'applicazione web.

Non ho ben capito se queste librerie sono le tue o se sono scritte da terzi. Comunque, aggiungerle nella cartella bin non è una buona pratica perché dovrebbero essere referenziate dal progetto e poi, per effetto della compilazione, te le ritroveresti nella cartella bin.

Comunque, se le librerie sono di terze parti, in ASP.NET Core le puoi ottenere come pacchetto NuGet lanciando il comando dotnet add package nomepacchetto.
Se le librerie sono tue, dovresti anche in questo caso valutare l'ipotesi di farne un pacchetto NuGet e pubblicarlo in un tuo feed privato come leggi qui.
Se invece non hai alternative (es. la dll è stata prodotta da qualcun altro che non l'ha pubblicata come pacchetto NuGet) allora la puoi referenziare direttamente nel progetto modificando il file .csproj come vedi qui:
https://stackoverflow.com/questions/46815546/how-to-add-external-assembly-dll-to-net-core-2-0-on-visual-studio-code

ciao,
Moreno

Enjoy learning and just keep making
18 messaggi dal 06 settembre 2002
Ciao Moreno ti rispondo con piacere e ti ringrazio per la tua disponibilità.

Secondo te e' un pattern obiettivamente difficile da comprendere oppure sei riuscito a capire bene come funziona, magari anche grazie al libro, 
ma per tua preferenza personale preferisci non usarlo perche' pensi che sia inutilmente complicato?


Esattamente, e' proprio cosi'. Il modello MVC mi e' chiaro ma lo trovo inutilmente complicato.

Ti rigiro questa domanda con un esempio.
Con un minimo di conoscenza di ASP.NET Core e del linguaggio Razor ho creato una pagina "Salve mondo" con questi semplici passaggi:

1. con Visual Studio 2017 ho creato un progetto Applicazione Web (pagine Razor)

2. ho creato queste tre cartelle all'interno del progetto: \Areas\ProveRazor\Pages

3. ho aggiunto una pagina Razor chiamandola Index (Visual Studio ha creato i due file seguenti) e ho inserito il seguente codice

File: Index.cshtml

@page
@model WebApplication1.Areas.ProveRazor.Pages.IndexModel
<h1>Welcome</h1>

<p>Ciao @Model.Nome!</p>


File: Index.cshtml.cs

public class IndexModel : PageModel
{
    public string Nome { get; set; }

    public void OnGet()
    {
        Nome = "Salvo";
    }
}


4. ho compilato ed eseguito il progetto con F5

5. inserendo il seguente URL: localhost:2640/ProveRazor vedo la pagina Welcome!!

Chiaramente questo e' un esempio molto banale, ma obiettivamente parlando quante classi avrei dovuto scrivere per arrivare a questo stesso risultato con MVC?

Controller? Routing? Action?

In ASP.NET Core MVC, bisogna capire bene i concetti di TempData, RouteCollection, ViewData, Action Controller, e Custom Route.
Non e' possibile creare un'applicazione Web utilizzando ASP.NET Core MVC finche' non si imparano tutti questi concetti basilari.

Trovo che con Razor Pages i file sono piu' organizzati.
C'e' una Razor View e il file del code behind: come nel buon vecchio ASP.NET Webforms!!

Non dico che all'aumentare della complessita' di un'applicazione le cose rimangano sempre cosi' semplici, ma mi sembra che il modello Razor Pages consenta un migliore controllo.
Cosa che significa: rapidita' di sviluppo e semplicita' di manutenzione.

Naturalmente dietro queste mie considerazioni puo' anche esserci (lo ammetto) un problema culturale e di gusti personali.

Riguardo invece alla domanda che ti ho fatto sulle DLL, chiarisco meglio.


Parliamo di DLL alcune sviluppate da me e altre di terze parti come ad esempio Newtonsoft.Json.dll.
Nel mio sito ASP.NET Webforms basta copiarle nella cartella c:\inetpub\wwwroot\bin per averle pronte all'utilizzo.
Posso anche inserire del codice C# nella cartella c:\inetpub\wwwroot\App_Code, che poi posso richiamare da tutte le pagine ASP.NET.

In ASP.NET Core l'unica soluzione e' passare per NUGet?

Grazie
salvo
11.097 messaggi dal 09 febbraio 2002
Contributi
Ciao Salvo, grazie per il post, è ben gradito.

Devo integrare quello che ti ho scritto prima.

Puoi restituire un file all'utente usando un Controller di ASP.NET Core MVC.


In realtà puoi anche fare tutto da una Razor Page, non serve creare un apposito controller. Leggi qui:
https://www.mikesdotnetting.com/article/318/working-with-json-in-razor-pages
Nel caso in cui tu debba restituire del json, puoi semplicemente creare un altro metodo nella stessa Razor Page chiamato ad esempio OnGetCarList() e richiamarlo da ajax con una richiesta GET all'url "nomerazorpage/CarList".
In quell'articolo trovi anche un link ai "named handlers", leggi anche quello perché è importante alla comprensione.


Chiaramente questo e' un esempio molto banale, ma obiettivamente parlando quante classi avrei dovuto scrivere per arrivare a questo stesso risultato con MVC?

Per realizzare quell'esempio avresti dovuto scrivere una classe in più: il model per la view.
Con RazorPages, il "codebehind" agisce contemporaneamente da controller e da model per la view (anche chiamato "viewmodel"). Con MVC, invece, queste sono classi separate. Vediamo il tuo esempio declinato in MVC.

La view razor resta quasi identica:
//File: /Views/Home/Index.cshtml
@model WebApplication1.Models.ViewModels.HomeViewModel
<h1>Welcome</h1>

<p>Ciao @Model.Nome!</p>


Creiamo ora la classe del view model, che è la classe extra da creare.
//File: /Models/ViewModels/HomeViewModel.cs
namespace WebApplication1.Models.ViewModels {
  public class HomeViewModel {
    public string Nome { get; set; }
  }
}


Ora creiamo il controller, che assomiglia al codebehind di una Razor Page. Come differenza, nota come la proprietà Nome non appartenga al controller ma alla classe HomeViewModel che abbiamo creato qui sopra.
//File: /Controllers/HomeController.cs
public class HomeController : Controller
{
    public IActionResult Index()
    {
        var viewModel = new HomeViewModel { Nome = "Moreno" };
        return View(viewModel);
    }
}


La differenza quindi non è moltissima e infatti sia MVC che Razor Pages sono state costruite sullo stesso stack tecnologico.

Il fatto che si debba creare una classe in più, generalmente, non è un problema. Qualcuno lo preferisce perché così tiene separate le responsabilità del controller, che sono quelle di coordinare la produzione di un risultato per l'utente, dalla responsabilità di un viewmodel che è semplicemente quella di trasportare dei dati. E' un po' lo stesso motivo per cui alcuni preferiscono tenere la lavatrice in bagno mentre altri nel garage.

Forse l'unica difficoltà di MVC consiste nel capire come ASP.NET Core mappa le richieste ai rispettivi controller e action. In Razor Pages, invece, il file .cshtml esiste fisicamente e quindi basta digitarne il nome nell'url per richiamarlo.
Inoltre, i file di codice di MVC sono organizzati per responsabilità ("Controllers", "Models" e "Views") mentre nel caso di Razor Pages i file correlati (view e codebehind) si trovano vicini, nella stessa cartella.

Comunque, sia MVC che Razor Pages sono approcci ugualmente validi per costruire applicazioni, quindi puoi scegliere quello che preferisci. Credo che gli sviluppatori siano spaccati in due in questo riguardo: chi preferisce continuare ad usare MVC è molto probabile che abbia odiato WebForms e le abitudini sono dure da cambiare.


In ASP.NET Core l'unica soluzione e' passare per NUGet?

NuGet è la soluzione di gran lunga preferita perché ti permette di procurarti una libreria in maniera molto facile. Basta digitare:
dotnet add package Newtonsoft.Json


Aggiungere la dll nella directory bin non è sufficiente perché, nel momento in cui vuoi usare l'oggetto JsonConvert, la compilazione fallirebbe. E' necessario che il riferimento alla libreria sia presente nel file .csproj, e questo viene aggiunto automaticamente quando ottieni la libreria con NuGet.

Invece, per quanto riguarda le tue librerie, se per il momento preferisci non inserirle in pacchetti NuGet, puoi aggiungere manualmente il riferimento alla .dll nel file .csproj come ti dicevo prima. Trovi le istruzioni qui:

https://stackoverflow.com/questions/46815546/how-to-add-external-assembly-dll-to-net-core-2-0-on-visual-studio-code


ciao,
Moreno
Modificato da BrightSoul il 23 settembre 2018 20.08 -

Enjoy learning and just keep making
66 messaggi dal 12 febbraio 2016
Buongiorno a tutti e scusate l'intrusione.
Vorrei dire la mia opinione in quanto mi trovo nella stessa situazione di Pennisi.
Anche io preferisco le webforms in quanto sono più semplici da mantenere: ad esempio se devo modificare qualcosa in una specifica pagina, io intervengo direttamente sul file aspx e provvedo a pubblicarlo sul server.
In MVC invece innanzitutto devo gestire il codice su tre file diversi, e dopo aver apportato una modifica su di una view devo ogni volta compilare il sito web e pubblicare tutti i files che lo compongono.
Questo porta a impiegare più tempo, mentre con le webforms basta pubblicare solo i files modificati.


Peccato che con la verione core le webforms non siano più consentite.
Ciao a tutti
11.097 messaggi dal 09 febbraio 2002
Contributi
Ciao Piero, nessuna intrusione, anzi, grazie per la tua opinione.


Anche io preferisco le webforms in quanto sono più semplici da mantenere: ad esempio se devo modificare qualcosa in una specifica pagina, io intervengo direttamente sul file aspx e provvedo a pubblicarlo sul server.

A partire da ASP.NET Core 2.1, quando pubblichi l'applicazione con il comando dotnet publish, le view vengono precompilate per default in un assembly NomeApplicazione.Views.dll e quindi non sarebbero aggiornabili. Puoi ridefinire questo comportamento impostando questa proprietà nel file .csproj. Mettilo nel primo PropertyGroup.

<MvcRazorCompileOnPublish>false</MvcRazorCompileOnPublish>


In questo modo, se devi ritoccare qualcosa in una view, puoi ripubblicare solo quella. Attenzione perché questo vale solo per il file .cshtml. Se cambi il codice del code behind devi comunque ripubblicare.

Però questo non è più un problema se usi un sistema che ti fa le build automatiche. In pratica, fai un commit nel repository GIT (o altro sistema di controllo di versione) e questo innesca una build del codice, l'esecuzione di eventuali unit test per verificare che non si sia rotto niente, e la successiva messa in produzione. Questo è anche un meccanismo di difesa che ridure il numero di bug che arrivano in produzione. di fatto il tempo che prima era dedicato alla pubblicazione manuale si riduce quasi a zero.

ciao,
Moreno

Enjoy learning and just keep making

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.