Convenzione Models/Data

di il
3 risposte

Convenzione Models/Data

Vi parlo da quello che ho studiato nei libri
Vi parlo della directory MVC che per convenzione contine gli oggetti del db e il contex per la connessione al db...
Da core 2 viene creata una nuova directory Data che per convenzione dovrebbe avere solita funzione...
ho capito bene?

3 Risposte

  • Re: Convenzione Models/Data

    GianmarcoInFossa ha scritto:


    Vi parlo della directory MVC che per convenzione contine gli oggetti del db e il contex per la connessione al db...
    Da core 2 viene creata una nuova directory Data che per convenzione dovrebbe avere solita funzione...
    ho capito bene?
    La convenzione prevede che la cartella Models contenga i tipi che costituiscono la "business logic" dell'applicazione, ovvero tutto ciò che esula dal contesto MVC e rappresenta la logica del sistema da implementare, che deve essere indipendente da come questa viene poi esposta, ad esempio tramite l'interfaccia utente realizzata con una applicazione Web ASP.NET MVC.

    Tuttavia, questa indicazione è molto blanda, tant'è che io utilizzo quella cartella solo per i modelli da passare alle viste: la logica di business dovrebbe essere invece implementata creando dei progetti separati, ovvero delle Class Library, affinché possa essere potenzialmente utilizzata al di fuori dell'applicazione ASP.NET MVC.

    A quel punto, è possibile creare diversi progetti a seconda dell'ambito da implementare: uno per le entità di base ed eventuali DTO, uno per le classi che costituiscono la logica, uno che fornisce l'implementazione dei servizi per l'accesso ai dati, uno per i servizi esterni (es. invio mail, ecc.) e così via, separando nettamente tutto ciò che fa parte del "core" da quello che invece è una implementazione specifica (basata su librerie e dipendenze particolari, oppure focalizzata a un ambito circostanziato).

    Ciao!
  • Re: Convenzione Models/Data

    Effettivamente hai completamente ragione a pensarci bene l utilizzo di directory è estremamente limitativo
    molto meglio organizzare la soluzione o in librerie o progetti, che si occupano di compi specifici. Un dubbio però
    Nel caso in cui la soluzione sia divisa in sottoprogetti può, in qualche caso essere creare ridondanza?:
    caso un cui una soluzione abbia due progetti o più che fanno riferimento alla solita libreria?
    using Microsoft.EntityFrameworkCore;

    Non voglio essere frainteso
    Supponendo che stia sviluppando la soluzione DBFelici.snl
    Dentro la soluzione Metto 2 progetti: dati, operazioni dati
    i quali utilizzano entity framework using Microsoft.EntityFrameworkCore;

    Soluzione DBFelici2.snl organizzo con directory

    Compilo DBFelici.snl e DBFelici2.snl poi hanno dimensioni simili?
  • Re: Convenzione Models/Data

    GianmarcoInFossa ha scritto:


    Nel caso in cui la soluzione sia divisa in sottoprogetti può, in qualche caso essere creare ridondanza?:
    caso un cui una soluzione abbia due progetti o più che fanno riferimento alla solita libreria?
    Dipende da qual è la ridondanza. Se parliamo di "codice duplicato che fa la stessa cosa", sicuramente andrebbe fattorizzato facendo in modo che ve ne sia una sola versione, magari configurabile per diversi scenari.

    Lo stesso dicasi per riferimenti a librerie e package: che due o più progetti abbiano la stessa dipendenza non è in genere un problema, però questo dipende anche dal tipo di libreria. Ad esempio, nel caso citato di Entity Framework, io mi aspetto che vi sia un solo e unico progetto (oltre a quello principale, ovvero quello dell'applicazione) che faccia uso di quella dipendenza, poiché si tratta di uno strumento per l'accesso ai dati e pertanto il codice implementativo che carica/salva i dati sul database deve essere localizzato (o si presume che sia) in un solo progetto: quello che ereditando le classi base del "core" dell'applicazione fornisce il "servizio" di accesso ai dati, appunto, implementato usando EF, ed eventualmente sostituibile in qualsiasi momento con un altro progetto che sostituisce quella implementazione e ne fornisce una basata su - che ne so - Dapper.

    Per capire come strutturare il codice, e di conseguenza anche i progetti, a prescindere dal linguaggio suggerisco di approfondire i principi SOLID.

    Ciao!
Devi accedere o registrarti per scrivere nel forum
3 risposte