Architettura della classe del progetto Web

No, non è una buona idea. A meno che tu non stia facendo un lavoro molto speciale, non hai bisogno di sovrascrivere le classi principali del framework. Problema con framework ricchi, ad es. .net e java sta capendo che il framework richiede tempo in base alle parti che usi maggiormente. Solo dopo questo, le strutture riducono il carico di lavoro. Questi framework sono progettati dai migliori ingegneri, quindi se hai bisogno di sovrascriverli molto, probabilmente non sai dove sia la funzionalità che stai cercando o come implementarla. Ho letto da qualche parte che il tempo è come il denaro:

1. Puoi spenderlo (facendo qualcosa)
2. Puoi salvarlo (usando gli strumenti appropriati)
3. Puoi investire (spendendone un po 'ora, per risparmiare molto più tardi)

Quando crei un'applicazione, la maggior parte di ciò che stai facendo dovrebbe essere indipendente dal framework. Il framework dovrebbe essere un dettaglio sul lato, non una parte integrante al centro dell'applicazione. Pensalo come un meccanismo di consegna o così. Lo stesso vale per i database e quant'altro. Se crei dei limiti appropriati, sarai in grado di cambiare database, interfaccia utente, routing framework, ecc, senza dover riscrivere l'applicazione.

Ciò significa che in generale non è una buona idea far funzionare la tua app con classi che ereditano da cose al di fuori del limite del tuo pacchetto. Difficile creare un accoppiamento più stretto o una maggiore dipendenza che poi eredita. Esp mixing nel logging sembra sbagliato.

Nell'argomento di registrazione - fare molta attenzione su quale codice di registrazione si è inserito in un DbContext. Se questo DbContext accetta un logger usando una bella interfaccia di Logger, allora può funzionare. Altrimenti probabilmente stai violando il principio di Responsabilità Singola.

Non è una buona idea sovrascrivere le classi del framework, anche quando è previsto dagli autori del framework. "Preferisci sempre la composizione sull'ereditarietà" - regola ampiamente conosciuta. Sostituire il codice del framework rende il tuo codice più dipendente e strettamente accoppiato con il codice del framework.

E solo per notare: il nome di "Masterpage" ha l'aspetto di un oggetto antipattern "God-object".

In computer programming, a software framework is an abstraction in which software providing generic functionality can be selectively changed by additional user-written code, thus providing application-specific software. A software framework is a universal, reusable software platform to develop applications, products and solutions. Software frameworks include support programs, compilers, code libraries, tool sets, and application programming interfaces (APIs) that bring together all the different components to enable development of a project or solution.

Framework è un insieme di classi e utilità che ha alcune funzioni di base ma allo stesso tempo non è autonomo. Framework ha molti hook che puoi sovrascrivere alla tua logica e ha molti buchi che devi riempire con la tua logica. Come l'interfaccia e la classe astratta, ad esempio. A meno che tu non stia facendo un lavoro speciale che ha bisogno della tua logica, sei libero di usare la logica generale di base.

Per un esempio, possiamo usare il sistema di appartenenza ASP.NET nella nostra applicazione ASP.NET. Agirà con la logica generale di appartenenza. Ma se abbiamo bisogno di una situazione speciale che è speciale per la tua applicazione, allora devi ereditare e sovrascrivere le classi del provider di appartenenze per dare la tua implementazione.