È la mia applicazione ASP.NET MVC strutturata in modo corretto?

Question

Ho lavorato attraverso le esercitazioni (in particolare quelli che utilizzano LINQ to Entities) e capisco i concetti di base, tuttavia alcune cose mi stanno dando problemi.

I tutorial di solito comportano solo i modelli semplici e forme che utilizzano solo di base creare, aggiornare e DELETE. I miei sono un po 'più complicato, e io non sono sicuro di andare su questo il modo giusto, perché quando arriva il momento di gestire i rapporti di oggetti di database una mezza dozzina, i tutorial smettono di aiutare.

Per il metodo post, il consueto modo di effettuare operazioni CRUD

entities.AddToTableSet(myClass);
entities.SaveChanges();

non fare quello che voglio, perché una classe piena attuazione non è sempre registrato al metodo di controllo. Posso inviare singoli campi, collezioni di forma, o più oggetti DTO e quindi chiamare un metodo su un servizio o un repository per prendere le informazioni che ricevo da un post modulo, insieme alle informazioni di cui ha bisogno per eseguire una query o creare per sé, e poi da tutte queste cose, creare il mio oggetto di database che posso salvare.

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Add(int id, [Bind(Exclude = "Id")] ClassA classA,
                        [Bind(Exclude = "Id")]ClassB classB)
{
   // Validation occurs here

   if(!ModelState.IsValid)
      return View();

   try
   {
      _someRepositoryOrService.Add(id, classA, classB);
      return RedirectToAction("Index", new { id = id });
   }
   catch(Exception ex)
   {
      // Logging and exception handling occurs here
   }
}


public void Add(int id, ClassA classA, ClassB classB)
{
    EntityA eA = new EntityA
    {
        // Set a bunch of properties using the two classes and
        // whatever queries are needed
    };

    EntityB eB = new EntityB
    {
        // Set a bunch of properties using the two classes and
        // whatever queries are needed
    };

    _entity.AddToEntityASet(eA);
    _entity.AddToEntityBSet(eB);
    _entity.SaveChanges();
}

Sono che la manipolazione di questo in modo corretto o sto bastardizing il quadro? Non ho mai fatto uso un oggetto entità direttamente, ogni volta che una query per quello che ho messo le informazioni che ho bisogno in un DTO e la base di mie opinioni fuori di questo. Lo stesso vale con la creazione. E 'questo permesso, o è la mia evitare usando le entità direttamente andando contro lo scopo di utilizzare il quadro?

Edit: Sono anche preoccupato per questo approccio perché richiede costruttori vuoti per fare correttamente le query LINQ a causa di questo messaggio di errore:

  

Solo costruttori senza parametri e   initializers sono supportati in LINQ to   Entità.

Questo non è un grosso problema dato che raramente ho bisogno di logica int costruttori, ma questo è un problema di non avere costruttori e solo le proprietà pubbliche?

Answer 1

_someRepositoryOrService.Add (id, classA, ClassB);

Direi che si paio con i repository livello di presentazione. Questo non dovrebbe essere. I repository dovrebbero lavorare solo con le entità. Avanti, notare come il vostro metodo Add

public void Add (int id, ClasseA classA, ClassB ClassB)

rompe la separazione degli interessi (SoC). Si esegue due attività:

1. Visualizza mappa dati in entità
2. salva al repository

Ovviamente il primo passo dovrebbe essere fatto in strato di presentazione. Considerare l'utilizzo di leganti modello per questo. Può anche aiutare a risolvere il problema costruttori, dato che i vostri raccoglitori del modello possono essere messi a conoscenza dei requisiti di costruzione.

Controlla anche questo eccellente posta da Jimmy Bogard (co-autore di ASP.NET MVC In Azione) su ViewModel. Questo potrebbe aiutare ad automatizzare la mappatura. E 'anche suggerire una tecnica invertita - rendere il vostro controller lavorano con gli enti, non ViewModels! filtri d'azione personalizzati e leganti di modello sono davvero la chiave per eliminare la routine che che non appartengono veramente ai controller, ma piuttosto un dettaglio infrastrutturale tra vista e il controller. Ad esempio, qui 's come automatizzo entità retrival. Qui 's come vedo che cosa dovrebbero fare i controllori .

L'obiettivo qui è quello di rendere i controllori contentrate sulla gestione logica di business, mettendo da parte tutti i dettagli tecnici che non appartengono alla vostra attività. E 'vincoli Techical che parlare in questo argomento, e si far loro perdite nel codice. Ma è possibile utilizzare strumenti MVC per spostare il loro livello di infrastrutture.

UPDATE: No, i repository non devono gestire i dati sotto forma, questo è ciò che intendo per "accoppiamento con presentazione". Sì, i repository sono nel controller, ma non funzionano con i dati del modulo. È possibile (non che si dovrebbe) far funzionare form con i "repository di dati" - vale a dire le entità - ed è quello che la maggior parte degli esempi fanno, ad esempio, NerdDinner - ma non il contrario. Questo è a causa della regola generale - strati superiori possono essere accoppiati con quelli inferiori (presentazione accoppiato con repository ed entità), ma mai basso livello devono essere accoppiati a quelli più alti (entità dipendono repository, repository dipendono modello forma, ecc ).

Il primo passo dovrebbe essere fatto nel repository, che è di destra - se non che la mappatura da ClassX a EntityX non appartiene a questo passo. E 'mappatura preoccupazione - un'infrastruttura. Vedi ad esempio questa domanda sulla mappatura, ma in generale se si avere due strati (UI e repository) non dovrebbero preoccuparsi di mapping - un servizio mapper / helper dovrebbe. Accanto blog di Jimmy, si può anche leggere ASP.NET MVC In Azione o semplicemente guardare la loro CodeCampServer per come lo fanno mappatura con interfacce IEntityMapper passati ai costruttori di controller (si noti che questo è più manuale e approccio meno-lavoro che di Jimmy Bogard automapper).

Ancora una cosa. Leggi Domain Driven Design, cercare gli articoli, imparare da loro, ma non si deve seguire tutto. Queste sono le linee guida, non soluzioni rigorose. Vedere se il vostro progetto in grado di gestire questo, vedere se è possibile gestire questo, e così via. Cercare di applicare questa tecnica, dato che sono in genere i modi eccellenti e approvati di fare lo sviluppo, ma non prendere ciecamente -. È meglio imparare lungo la strada che per applicare qualcosa che non si capisce

Answer 2

Direi usando DTOs e avvolgendo l'Entity Framework con i propri metodi di accesso ai dati e lo strato di business è un ottimo modo per andare. Si può finire per scrivere un sacco di codice, ma è un'architettura di meglio che fingere il codice generato Entity Framework è il vostro livello di business.

Questi problemi non sono realmente necessariamente legati ad ASP.NET MVC in alcun modo. ASP.NET MVC dà praticamente alcuna indicazione su come fare il vostro modello / accesso ai dati e la maggior parte dei campioni e tutorial per ASP.NET MVC non sono degni di produzione implementazioni modello, ma in realtà solo i campioni minimi.

Sembra che si è sulla strada giusta, andare avanti.

Alla fine, si utilizza Entity Framework per lo più come un generatore di codice che non sta generando il codice molto utile e quindi si consiglia di guardare in altri generatori di codice o strumenti o framework che corrispondono più da vicino le vostre esigenze.