C'è una ragione per evitare un accoppiamento stretto con una classe modello?

Question

C'è una ragione per evitare un accoppiamento stretto con una classe modello?

#1 da (2 voti)
#2 da (1 voti)

0

Con questo intendo qualcosa come Student, che sta modellando una riga della tabella Studente:

class Student
{
    public string lastname;
    public string firstname;
}

Non ha senso per me programmare su un'interfaccia o anche ereditare da una classe "normale". Non vedo davvero dove dovrei preoccuparmi di accoppiare qui, se sto usando qualcosa come Entity Framework (o qualsiasi altra astrazione al database), dove ho già un Separation of Concerns.

Prima o poi devo sapere quale classe dovrei usare, e ho difficoltà a vedere eventuali problemi che potrei avere in futuro con un accoppiamento stretto con la classe modello .

Anche se ho,

class Student extends Person
{
    public string lastname;
    public string firstname;
}

Quindi più tardi posso farlo,

public function myFunc (Person somestudent)
{
    Person myPerson = somestudent;
}

Non vedo il vantaggio perché voglio sapere se qualcuno è davvero un oggetto Studente.

Ho visto questi,

Come gestire l'accoppiamento in classi di modelli

Database condiviso vs modello di messaggio strettamente accoppiato

C # - Design basato sui dati & Accoppiamento - Mamma, posso? (non sembra che risolva il problema)

coupling

posta johnny 14.08.2017 - 17:34

fonte

2 risposte

2

L'accoppiamento, come tutto il resto nell'informatica, è un compromesso. Vuoi un accoppiamento libero quando ti sarà utile. L'accoppiamento che si verifica tra l'applicazione e il framework .NET, oi pacchetti scaricati tramite Nuget, è l'accoppiamento più stretto che ci sia.

Nelle applicazioni line-of-business, l'accoppiamento libero entra in gioco quando si desidera andare oltre le semplici operazioni CRUD ai processi aziendali attuali. In assenza di tale requisito, è possibile utilizzare semplicemente i DTO generati forniti da Entity Framework. Entity Framework offre anche funzionalità di "unità di lavoro" gratuite.

Considera, ad esempio, una fattura. Una fattura è inevitabilmente un artefatto aziendale. Non si archiviano clienti o prodotti nelle fatture; piuttosto, si guardano quelle cose da un database, e poi si fa riferimento per ID. Il livello aziendale si traduce tra gli oggetti di business (la fattura) e le operazioni CRUD (persone e cose, entità). In tal modo, in genere crea un oggetto ViewModel che contiene tutte le entità richieste per la fattura. È qui che entra in gioco il tuo accoppiamento lento.

risposta data 14.08.2017 - 18:00

fonte

Leggi altre domande sui tag coupling

C'è un vantaggio nell'utilizzo di AJAX piuttosto che in un semplice window.location? Esempi chiari per gli odori di codice [chiuso]

score 1 · Accepted Answer

Il motivo principale per l'utilizzo di un'interfaccia è principio di sostituzione di Liskov . Se aderisci a LSP, puoi sostituire una classe diversa per diversi scenari, ad es. per test delle unità.

Detto questo, se il tuo modello è semplicemente un semplice contenitore di dati - contiene solo proprietà di lettura / scrittura e non ha alcun comportamento - c'è ben poco da sostituire. Il tuo codice di test dell'unità può semplicemente utilizzare il modello originale anziché un mock o uno stub. Non è assolutamente necessario utilizzare un'interfaccia con questo tipo di modello. Io no.