Ciao,
Vorrei creare un piccolo sito ecommerce, possibilmente usando solo Razor (senza MVC)
Certo, è possibile, con ASP.NET Core 2 puoi creare un'applicazione usando le Razor Pages. Probabilmente già le conosci ma ti linko lo stesso la documentazione:
https://docs.microsoft.com/en-us/aspnet/core/razor-pages/?view=aspnetcore-2.1&tabs=visual-studioE un piccolo esempio:
https://github.com/BrightSoul/RazorPagesSampleApp
Sono un pò perso per quanto riguarda la struttura delle cartelle.
Sei libero di strutturare il progetto come preferisci. Le uniche cartelle da conoscere sono:
- wwwroot: metti qui i file statici dell'applicazione (immagini, file css, file javascript);
- Pages: qui vanno le razor page .cshtml, eventualmente organizzate in sottocartelle;
- Areas: per creare dei "compartimenti" nella tua applicazione. Ad esempio, dato che realizzerai un ecommerce, potresti mettere le pagine della parte pubblica del sito nella cartella /Pages mentre le pagine per l'area riservata agli amministratori (che è una porzione di applicazione destinata ad un nucleo ristretto di utenti) le potresti inserire sotto /Areas/Admin/Pages.
Leggi qui a proposito delle Areas.
http://www.aspitalia.com/articoli/asp.net-core/anteprima-aspnet-core-2-1-parte-2.aspx
A parte queste cartelle, puoi crearne altre e dargli i nomi che desideri per organizzare il codice secondo il tuo senso d'ordine personale.
Però, guardando alcuni esempi, ho visto alcuni che hanno "DataLayer", altri "Services", "Models", ecc...
Penso che "DataLayer" sia stato usato per inserire al suo interno le classi relative all'accesso ai dati. La logica di accesso al db è meglio che non sia direttamente nelle Razor Page: se la tieni in classe apposite la potrai riutilizzare più facilmente da tutte le pagine che ne hanno bisogno, ed evitando di duplicare il codice.
"Services" è una cartella che di solito uso anch'io per inserirci servizi di vario tipo. Per "servizio" intendo una classe che è in grado di offrire una funzionalità al resto dell'applicazione, come ad esempio: creazione della thumbnail di un'immagine, creazione di una fattura PDF, invio di un'email e così via. Io dentro "Services" metto anche le classi di accesso al database perché alla fine considero la lettura/scrittura su database essa stessa un servizio offerto all'applicazione.
Quando comincio ad avere parecchie classi nella cartella Services, creo delle sottocartelle per fare un po' d'ordine. Quindi ho Service/Data per l'accesso al database, Services/Media per lavorare con immagini e PDF, Services/Web per le classi che uso per collegarmi a web api di terze parti, e così via.
Questo però è quello che mi dice il mio ordine personale, tu puoi pensarla in altro modo e organizzare il codice come credi. Se guardi
questo esempio, vedi che la logica di accesso al db è stata messa in una cartella chiamata Infrastructure/Data mentre le classi del modello sono state inserite dentro Core.
"Models" di solito contiene entità e dto. Per "entità" si intende una classe che rappresenta un oggetto reale, come "Prodotto" o "Ordine" e all'interno del quale dovresti inserire della logica di business (es. lo stato dell'oggetto Ordine non può passare a "Spedito" se prima non risulta "Pagato").
Per "dto" invece si intende una classe anemica, che ha solo proprietà e nessuna logica. Questo genere di classi si usano solitamente per restituire dati al client (es. vuoi caricare con una richiesta ajax l'elenco dei risultati di ricerca per mostrarli all'utente mentre digita nella casella).
Saper organizzare il codice in cartelle non è poi così essenziale. L'importante invece è saper mantenere classi piccole, con responsabilità molto specifiche, in modo che possano essere composte e riutilizzare più facilmente dall'applicazione. Per usare queste classi, usa la funzionalità di dependency injection di ASP.NET Core come se non ci fosse un domani. Qui trovi una discussione in merito.
http://forum.aspitalia.com/forum/post/420254/Accedere-AppSettings-Classe.aspxciao,
Moreno
Modificato da BrightSoul il 21 agosto 2018 20.50 -
