Migliore architettura per l'applicazione Web.Forms ASP.NET

Ho scritto un portale ASP.NET WebForms per un client. Il progetto si è evoluto piuttosto che essere adeguatamente pianificato e strutturato sin dall'inizio. Di conseguenza, tutto il codice viene unito nello stesso progetto e senza livelli. Il client ora è soddisfatto della funzionalità, quindi vorrei riformattare il codice in modo tale da essere sicuro di rilasciare il progetto. Poiché sembrano esserci molti modi diversi di progettare l'architettura, vorrei alcune opinioni sull'approccio migliore da adottare.

FUNZIONALITÀ

Il portale consente agli amministratori di configurare modelli HTML. Altri "partner" associati saranno in grado di visualizzare questi modelli aggiungendo il codice IFrame al loro sito. All'interno di questi modelli, i clienti possono registrarsi e acquistare prodotti. È stata implementata un'API utilizzando WCF che consente alle aziende esterne di interfacciarsi anche con il sistema. Una sezione di amministrazione consente agli amministratori di configurare varie funzionalità e visualizzare report per ciascun partner. Il sistema invia fatture e notifiche e-mail ai clienti.

ARCHITETTURA ATTUALE

Attualmente utilizza EF4 per leggere / scrivere nel database. Gli oggetti EF vengono utilizzati direttamente all'interno dei file aspx. Ciò ha facilitato il rapido sviluppo mentre stavo scrivendo il sito, ma è probabilmente inaccettabile mantenerlo così poiché combina strettamente il db con l'interfaccia utente. È stata aggiunta una logica aziendale specifica alle classi parziali degli oggetti EF.

DOMANDE

L'obiettivo del refactoring sarà quello di rendere il sito scalabile, facilmente gestibile e sicuro.

Quale tipo di architettura sarebbe la migliore per questo? Descrivi cosa dovrebbe essere in ogni livello, se dovrei usare il modello DTO / POCO / Active Record ecc.
Esiste un modo affidabile per generare automaticamente DTO / BO in modo che eventuali miglioramenti futuri siano facili da implementare nonostante i livelli extra?
Sarebbe utile convertire il progetto da WebForms a MVC?

— impilare l'uomo
fonte

Rilasciare presto, rilasciare spesso. Suggerisco che al tuo cliente potrebbe non interessare così tanto se non hai problemi commerciali tangibili da presentare (ad esempio, non è sicuro). Forse dovresti ripulire un po '(assicurati che sia portatile) e rilasciarlo, quindi prendilo come un'iniziativa a lungo termine - per trasformarti in MVC o simili.

— gahooa,

Non cambiare la tecnologia del tuo progetto di lavoro con la nuova tecnologia xyz solo perché è lì, specialmente se il tuo progetto sta funzionando bene così com'è. Se funziona, non romperlo. Al business non interessa il codice. La funzionalità è tutto ciò che conta alla fine della giornata.

— NoChance,

ok è vero, comunque la mia preoccupazione è che, una volta rilasciato, sarà più difficile rifattorizzare a causa del rischio di romperlo quando la posta in gioco è molto più alta. Quindi saremmo bloccati con un codice che non è così gestibile e più difficile da eseguire il debug, ecc. Ero tentato di apprendere / convertire in MVP ma sembrava troppo lavoro. Finora l'ho appena convertito in DAL, Domain, UI layer che sembra più organizzato ma consente comunque l'inevitabile RAD che sarà necessario mentre il progetto è giovane. Un giorno, se necessario, posso espandermi in MVP o MVC suppongo - dopo aver abbastanza tempo per imparare come funziona.

— Stack Man

Ciò che sembra ancora disordinato è: 1) EF Objects nell'interfaccia utente (codice dietro i file nel livello dell'interfaccia utente)

— stack man

(2) Logica aziendale in oggetti EF estesi che doveva andare nel livello DAL (non si rendeva conto che le classi parziali dovevano trovarsi nello stesso assieme) (3) Logica aziendale all'interno dei file aspx.cs nel livello UI. Tuttavia, sembra che ci siano spesso compromessi quando si tratta di architettura, ma questo è certamente un passo avanti. Sento che questo è accettabile per la prima versione e col passare del tempo possiamo rivalutare il nostro approccio. Grazie per il vostro aiuto a tutti. È bene avere un po 'di direzione in quanto questa zona è così soggettiva.

— Stack Man

Risposte:

Il modello ASP.NET MVP è l'architettura migliore per un'applicazione webforms ASP.NET a lungo termine . Sta entrando in gioco con il concetto di "separazione delle preoccupazioni", che è di fatto una tendenza alla base dei modelli MV *.

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

— Yusubov
fonte

Il problema è che richiederebbe molto lavoro per il refactoring del progetto su MVC ... se lo tengo come un'app WebForms con Domain Layer (codice prima, POCO), Data Access Layer (solo contesto db) e UI, consideri questo un design accettabile per la produzione? In un secondo momento potremmo considerare di convertirlo in MVC, suppongo.

— Stack Man

Bene, è un modello MVP (model-view-presenter) e NON un MVC (model-view-controller).

— Yusubov,

oh scusa, ho letto male. Grazie - Leggerò del design MVP.

— Stack Man

nessun problema, spero che troverai quello che cerchi :)

— Yusubov,

Sembra che anche la conversione in MVP sarebbe un grande cambiamento. Il client vuole rilasciare molto presto, quindi pensi che la summenzionata architettura DAL / DA / UI (anche se non ideale come MVP) sarebbe accettabile per questo tipo di applicazione? Quindi dopo il rilascio potremmo guardare al passaggio a MVP in v2.

— Stack Man

Usa il modello MVP per separato e logica e UI, quindi in futuro puoi passare a una tecnologia UI diversa riutilizzando la logica esistente
Utilizzare il modello di repository tra BL e DAL in modo da poter passare a qualsiasi RDBS riutilizzando la logica aziendale
portare strati separati (Dll) per BO e DAL, riducendo al minimo la manutenzione.

— Arunachalam
fonte

Non sono sicuro del motivo per cui qualcuno ha votato a fondo questa domanda. Ad essere onesti, questa è la risposta più concisa. +1

— Greg Burghardt,

Come accennato da ElYusubov, il modello MVP può essere eccezionale.

Il concetto chiave sta togliendo la maggior parte o tutta la tua logica dal code-behind. La logica non deve essere associata a una pagina. Cosa succede se è necessario riutilizzare la logica da una pagina in un'altra? Sarai tentato di copiare e incollare. Se lo stai facendo, il tuo progetto diventerà sostenibile.

Quindi, per cominciare, inizia a refactoring la tua logica dal code-behind e inseriscila 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 tuoi dati sia separato dalla tua logica aziendale. Crea un livello dati e inizia il refactoring anche a tale scopo. Dato che stai usando EF4, questo è meno un problema in quanto EF dovrebbe già avere questo scopo 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 aggiuntivo è che potrebbe essere necessario fare riferimento al modello di dati in altri progetti.

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

modificare

Hai chiesto di avere il codice dietro ereditare una classe di business logic. 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. Devi separare concettualmente la logica. È probabilmente il caso che il codice nel tuo code-behind stia facendo molte cose diverse. Una classe dovrebbe fare solo una cosa e una cosa. Prova a pensare a come puoi estrarre concettualmente le funzionalità esistenti. Ad esempio, supponiamo che tu abbia una pagina di registrazione e che stai raccogliendo informazioni sull'utente. Probabilmente hai un pulsante chiamato register e un evento click associato a quel pulsante. In tal caso stai salvando le informazioni dell'utente e eseguendo qualsiasi elaborazione di cui hai bisogno. È possibile creare un oggetto Registrazione per gestire tutta quella logica.

Questa non è solo una separazione più pulita, ma può anche essere un modo per documentare autonomamente 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 desidera seguire rigorosamente il modello MVP, invece di passare i parametri all'oggetto Registration il code-behind implementerebbe un'interfaccia. L'implementazione dell'interfaccia essenzialmente mapperebbe tutti gli oggetti vista (campo di testo ecc.) Sull'interfaccia. es. stringa pubblica FirstName {get {return txtFirstName.Text; }}

Fatto ciò, è possibile passare la pagina all'oggetto Regisration

Registration.RegisterUser (questo);

E questo metodo RegisterUser prenderebbe l'interfaccia come parametro

public bool RegisterUser (utente IUser) {user.FirstName ...}

interfaccia pubblica IUser {nome stringa pubblico; }

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

— programmatore
fonte

Grazie per i tuoi consigli utili. Sì, sono stato sicuramente un po 'sopraffatto da questo. Mi sembra che MVC sarebbe il modello migliore da usare, ma MVP sarebbe più facile da raggiungere e sarebbe il modello migliore successivo. Ho sempre usato il codice dietro i file, quindi mi sono sempre grattato la testa su come la logica aziendale può essere separata dalla presentazione ... quindi dovrei essere in grado di spostare essenzialmente i miei file .aspx.cs sul livello del dominio e avere un'istruzione eredita in aspx ? Sicuramente finire con 3 livelli mi farebbe sentire a mio agio con il rilascio della prima versione, quindi posso migliorarla da lì.

— Stack Man

Risponderò al tuo commento nella mia risposta. Sentitevi liberi di upvote la mia risposta, se hai trovato utile

— coder