Mvc4: N tier

Question

Strumenti: Mvc4, SQL server, NHibernate

Sto imparando l'architettura nTier e il piano per imparare questo con un piccolo esempio. Questa sarà una domanda di registrazione per studenti che avrà un modulo per a. nome b. cognome c. indirizzo d. ID studente L'applicazione sarà in grado di a. Chiedi agli studenti di Id b. Prendi tutti gli studenti c. Registrati nuovi studenti/Salva studente d. Modifica uno studente e. Eliminazione di uno studente

ho intenzione di avere i seguenti livelli

Presentazione strato (progetto separato MVC 4 applicazione)

--- html per la forma studente va qui. Posso usare jquery ecc. --- il mio controller chiamerà il servizio

Livello di servizio (progetto separato: progetto libreria di classi. In questo caso solo il web sarà il mio cliente. Imparerò a utilizzare webAPI o wcf per questo più tardi in un altro progetto)

--- StudentService qui

--- IstudentService qui

strato di business: (progetto separato: progetto di libreria di classi) ??

Livello dati: (progetto separato: progetto libreria di classi) ??

Database: (database di SQL Server)

Ora mi sono confuso e le mie domande sono: (? Quale livello)

1. dove posso creare il mio modello studente

2. Quale sarà Scrivo nel mio livello aziendale per questo esempio di studente che ho.

3. Cosa andrà nel mio livello dati? Quali metodi scriverò? Sono metodi che comunicano direttamente con il database ?

   Alcuni esempi saranno fantastici. Cercherò un buon contenitore di IOC.

Ecco il codice di esempio:

public interface IStudentService 

    { 
     IEnumerable<Student> GetStudents(); 

     Student GetStudentById(int id); 

     void CreateStudent(Student student); 

     void UpdateStudent(Student student); 

     void DeleteStudent(int id); 

     void SaveStudent(); 
    } 

public class StudentService : IStudentService 
    { 
     private DataContext _datacontext; 
     public StudentService() 
     { 
      _datacontext = new DataContext(); 
     } 

     public IEnumerable<Student> GetStudents() 
     { 
      var students = _datacontext.Students; 
      return students; 
     } 

     public Student GetStudentById(int id) 
     { 
      return _datacontext.Students.Find(id); 
     } 

     public void CreateStudent(Student student) 
     { 
      _datacontext.Students.Add(student); 
      _datacontext.SaveChanges(); 
     } 

     public void UpdateStudent(Student student) 
     { 
      _datacontext.Entry(student).State = EntityState.Modified; 
      //_datacontext.Entry(student).State = EntityState.Modified; 
      _datacontext.SaveChanges(); 
     } 

     public void DeleteStudent(int id) 
     { 
      var student = _datacontext.Students.Find(id); 
      _datacontext.Entry(student).State = EntityState.Deleted; 
      _datacontext.SaveChanges(); 
     } 

     public void SaveStudent() 
     { 
      _datacontext.SaveChanges(); 
     } 
    } 

Answer 1

È necessario avere uno sguardo su Onion Architecture. È un po 'obsoleto in termini di versioni MVC, ma i livelli sono stratificati notevolmente.

In termini di contenitore IoC, consiglierei di cercare su Autofac - facile da usare con molte funzionalità, come la registrazione per convenzione e multi-tenant.

Per quanto riguarda le vostre domande:

Quello che di solito ho è in forma presentare, regolatore otterrebbe un StudentViewModel presentata, quindi vorrei convertirlo in un oggetto Student e consegnare al IStudentRepository che viene iniettato nel controller. E IStudentRepositry lo salverà su DBContext. L'interfaccia del repository si trovava nel livello del dominio, ma l'implementazione del repository sarebbe nel livello dati. E il contenitore DI si abbinerà l'uno all'altro.

Il trucco qui è di avere tutte le interfacce nel livello di dominio e le implementazioni che si trovano ovunque dovrebbero essere. E il livello del dominio non dovrebbe dipendere da nessun altro livello (leggi il progetto del dominio non farebbe riferimento ai progetti Data e Web). Ma il Web dipenderebbe da livelli di dati e dominio. Hai solo bisogno della dipendenza del livello dati nel livello Web per configurare il contenitore IoC, poiché il livello web è la tua radice aggregata e IoC dovrebbe essere configurato lì. Ma non dovresti mai usare gli oggetti Data direttamente in nessuna delle operazioni, dovresti iniettare interfacce per repository o servizi.

Si è parlato molto dell'architettura a livelli, quindi iniziare con Onion Architecture prima, quindi avrete un'idea migliore di ciò che vi serve.

Answer 2

1. Si crea il modello nel livello dati. Creerai anche modelli nel tuo livello di presentazione (per i tuoi modelli di vista). Di solito esegui una sorta di mappatura tra il modello dati e il modello di presentazione nel controller.

2. Le app semplici spesso non hanno realmente bisogno di un livello aziendale. Soprattutto se l'app salva solo i dati dai moduli nelle tabelle. Tuttavia, in un'app come questa potresti fare cose come "Non puoi registrarti per questa classe a meno che tu non abbia già completato quella classe" o potresti avere "Ti sei già registrato per più classi di quante ne hai permesso" o cosa non. Queste sono regole aziendali che devono essere applicate da qualche parte e che di solito si trovano nel livello aziendale.

3. Il livello dati sarà probabilmente solo il modello di Entity Framework. È solo il tuo codice per caricare e salvare il tuo modello nel database.

ci sono molti contenitori IoC .. Mi piace Ninject, ma altre persone come altri quelli .. E 'generalmente una questione di preferenze personali.

Quanto sopra è come lo si dovrebbe fare in una semplice applicazione. Nelle applicazioni più complesse, potresti avere anche un modello nel tuo livello aziendale. Tutto dipende dalla complessità dell'applicazione e dalla necessità di rappresentare i dati a livello aziendale in modo diverso rispetto a quello a livello di modello di dati.

Ad esempio, si potrebbe avere un elenco di oggetti di business nel livello aziendale, ma questi oggetti sono rappresentati in modo diverso nel livello dati per motivi di prestazioni. Ma tutto questo non è davvero qualcosa di cui dovresti preoccuparti a questo punto. Capisci solo che le tue applicazioni diventano più complesse, potresti avere la necessità di fare le cose in modo diverso.