Migliore architettura per l'applicazione WebForms ASP.NET

Il pattern MVP di ASP.NET è la migliore architettura per l'applicazione a lungo termine di webform ASP.NET. Sta entrando in gioco con il concetto di "separazione delle preoccupazioni", che è di fatto una tendenza dietro i modelli MV *.

La domanda su Perché per usarlo? - affrontato in dettaglio in questo post - ASP.NET MVP

• Per iniziare con il test di un Applicazione Webforms ASP.NET
• Trade-off tra MVP vs MVC
• Fine della confusione : MVP vs MVC

Come ElYusubov ha menzionato, lo schema MVP può essere eccezionale.

Il concetto chiave sta eliminando la maggior parte o tutta la tua logica dal code-behind. La logica non dovrebbe essere legata a una pagina. Cosa succede se è necessario riutilizzare la logica da una pagina all'altra? Sarai tentato di copiare e incollare. Se lo fai, il tuo progetto diventerà manutenibile.

Quindi, per i principianti iniziare a rifare la tua logica dal code-behind e metterla in un livello aziendale. Se sei riuscito a ottenere tutta la logica dal code-behind, allora potresti implementare le interfacce necessarie per essere un vero MVP.

Assicurati inoltre che l'accesso ai dati sia separato dalla logica aziendale. Crea un livello dati e inizia anche il refactoring a tale scopo. Dato che stai usando EF4, questo è meno problematico in quanto EF dovrebbe già avere questo capo separato. Dovresti essere in grado di spostare facilmente tutti i tuoi file EF in un altro progetto e aggiungere semplicemente un riferimento ai progetti che ne hanno bisogno. Il vantaggio ulteriore è che potresti aver bisogno di fare riferimento al tuo modello di dati in altri progetti.

Per evitare di essere sopraffatto, aggiusta un po 'alla volta. Ogni volta che tocchi un pezzo di codice, considera il refactoring del codice che lo circonda. Se lo fai, nel tempo il tuo progetto può diventare più gestibile.

Modifica

Hai chiesto se il codice dietro eredita una classe di logica aziendale. Questo non può essere fatto perché il codice dietro la pagina "is-a". C # non consente l'ereditarietà multipla, quindi la classe code-behind non può essere sia una pagina che un oggetto personalizzato. È necessario separare concettualmente la logica. Probabilmente è il caso che il codice nel code-behind sta facendo molte cose diverse. Una classe dovrebbe fare una cosa e una sola cosa. Prova a pensare a come puoi concettualmente estrapolare funzionalità esistenti. Ad esempio, diciamo che hai una pagina di registrazione e stai raccogliendo informazioni sugli utenti. Probabilmente hai un pulsante chiamato registro e un evento click associato a quel pulsante. In tal caso, si salvano le informazioni dell'utente e si esegue qualsiasi elaborazione necessaria. È possibile creare un oggetto Registration per gestire tutta quella logica. Nel code-behind invece di fare la logica da solo, puoi passare le informazioni all'oggetto Registration.

Questo non solo è una separazione più pulita, ma può anche essere un modo per documentare automaticamente il tuo codice. Quando qualcuno legge il tuo codice, ti vede chiamare un oggetto Registration in modo da sapere esattamente cosa sta succedendo.

Se si volesse seguire rigorosamente il pattern MVP, invece di passare i parametri all'oggetto Registration il code-behind implementerebbe un'interfaccia. L'implementazione dell'interfaccia dovrebbe essenzialmente mappare tutti gli oggetti vista (campo di testo, ecc.) All'interfaccia. per esempio. public string FirstName {get {return txtFirstName.Text; }}

Fatto ciò potresti passare la pagina all'oggetto Regisration

Registration.RegisterUser (this);

E questo metodo RegisterUser prenderebbe l'interfaccia come parametro

RegisterUser pubblico (utenteUser) {user.FirstName ...}

interfaccia utente IUser {     stringa pubblica FirstName; }

Se questo MVP sembra confuso, concentrati solo sul refactoring e conosci il punto di tutto questo per massimizzare il riutilizzo del codice. Non c'è più da ripetersi. Questo è il principale DRY .

1. Utilizza pattern MVP per logica separata e interfaccia utente, quindi in futuro puoi passare a una diversa tecnologia dell'interfaccia utente riutilizzando la logica esistente
2. Utilizza il pattern di repository tra BL e DAL in modo che tu possa passare a qualsiasi RDBS riutilizzando la logica di business
3. porta livelli separati (DLL) per BO e DAL che riduce al minimo la manutenzione.