Qual è il valore di OOP in ASP.NET MVC?

Quando stavo imparando MVC in PHP, pensavo spesso che "questa roba OO è solo funzioni racchiuse da classi", soprattutto perché ero abituato a uno stile procedurale di codifica. Ma poi ho avuto sempre di più nella ricerca di modelli di progettazione, incapsulamento corretto, disaccoppiamento e teoria generale dietro l'OOP.

Posso dire che la comprensione dei principi OOP nel contesto di MVC ha davvero fatto la differenza nella parte del modello dell'app. Mentre i controller sono ancora già disposti e tutto ciò che devi fare è riempire i metodi di azione con il codice corretto, e le viste sono solo HTML con qualche codice qua e là, il modello è dove la conoscenza dei principi OO mostra. Quando hai qualcosa di più di una semplice applicazione CRUD morta, si tratta di pianificare le classi di dominio. Quindi si introduce un ORM come EF per occuparsi della persistenza e aggiungere alcuni repository per disaccoppiare dall'implementazione EF. Quindi implementa un'unità di lavoro per fare la persistenza per ogni richiesta. Quindi si getta in un contenitore DI come Unity, per mantenere tutto questo ben disaccoppiato, principalmente per consentire un corretto test.

L''"applicazione" è in sostanza il modello di dominio, con le classi di entità, i servizi e gli archivi, e se questa parte viene eseguita correttamente, non fa quasi nessuna differenza quale tipo di interfaccia utente si impone su di esso, sia esso un App MVC che serve pagine o qualche app REST che invierà JSON a un'app mobile o a un'app desktop. Un modello ben progettato può essere riutilizzato in diverse applicazioni.

Inoltre, conoscere i principi di OO renderà più facile capire come funziona la cosa MVC in primo luogo e aiutare a ripulire parte della "magia" che potrebbe accadere sotto le copertine, e renderà più facile cambiare lingue se necessario (e se anche l'altra lingua è orientata agli oggetti).

In conclusione, direi di sì, OOP e design sono essenziali.

Sono anche responsabile del colloquio tecnico nella mia azienda.
È difficile dirti quale sarebbe il mio numero uno in quanto mi piace che le persone abbiano una vasta conoscenza tecnica.

Tuttavia, una cosa è certa, anche se la maggior parte dei framework attuali che utilizziamo tendono ad astrarre la cosa OOP, gli sviluppatori dovrebbero sapere e capire almeno un po ', cosa stanno usando.

Dal mio punto di vista, OOP è ancora una parte importante da conoscere e capire.
Sono ancora stupito dal numero di persone che non riescono a spiegarmi l'utilità di un'interfaccia! O anche qual è la differenza tra un'interfaccia e una classe astratta!

Siamo davvero interessati a Clean Architecture e siamo fan di quello di Onion. Come può uno sviluppatore codificare l'Application Core senza sapere almeno che cos'è un'interfaccia?

Sapere come utilizzare EF, come scrivere alcuni MVC o avere conoscenze di base di JQuery, è alla portata di tutti gli sviluppatori.
Avere una buona conoscenza di ciò che OOP è, quanto è utile e quando è importante utilizzarlo, potrebbe essere la differenza fondamentale tra uno sviluppatore medio e il "one-that-you-really-want-to-hire.

Mi aspetto che uno sviluppatore C # abbia una buona conoscenza di OOP. Tuttavia, ho l'impressione dalla tua lista che il tuo sviluppatore sarà un generalista e non uno specialista di C #.

Se scegli i tuoi sviluppatori in base alle loro conoscenze OOP, potresti avere un controller e un modello molto puliti; ma potrebbero non essere in grado di scrivere query SQL ottimizzate in caso di necessità e la tua architettura front-end potrebbe finire per essere un disastro enorme.

Forse potresti provare ad assumere persone con competenze complementari.

Essendo che C # è un linguaggio orientato agli oggetti, suppongo che sia ovvio che OOP è sulla lista di controllo per uno sviluppatore C #, tuttavia è incredibile per me quanti programmatori (verdi o esperti) effettivamente comprendono e vivono con principi di OOP.

Se fossi in te probabilmente sostituirò il numero uno con principi SOLID .