Perché le persone antepongono i nomi delle proprietà ai nomi delle classi [chiuso]

Nella progettazione del database spesso accade che in una relazione di chiave esterna entrambi i campi su entrambi i lati della relazione abbiano lo stesso nome.

Ad esempio:

• bookings.booking_id (chiave primaria)
• payment.payment_id (chiave primaria)
• payments.booking_id (chiave esterna a bookings.booking_id)

L'uso di un nome di colonna chiave primaria che è univoco in tutto lo schema rende facile avere la colonna chiave esterna con lo stesso nome della chiave primaria a cui punta.

In questi casi, quando si utilizza un ORM, è naturale e conveniente usare lo stesso nome nelle entità ORM, ma con un involucro diverso. Una volta che uno sviluppatore prende questa abitudine, la applicherà ovunque, anche nel codice non ORM. Questo non lo rende giusto, ma spiega perché succede.

Avere il nome lungo FooId rende possibile trovare tutti gli usi della proprietà ovunque nel codice sorgente, che è utile avere. D'altra parte, potresti avere un editor che può cercare simboli e mantenere separate le proprietà Id di classi diverse. O hai uno strumento di refactoring che può mostrarti tutti gli usi di un simbolo.

Se non possiedi questi strumenti o non ne sai niente, i nomi lunghi sono utili.

Il prefisso delle proprietà della classe con il suo nome non è normale e una pratica molto strana. Ma se stai parlando nel contesto di Entity Framework, a volte potresti vedere qualcosa di simile a questo, dove vedi un ID della proprietà di navigazione con il prefisso del nome:

public class Foo {
    public int Id { get; set; }

    public Bar Bar { get; set; }

    public int BarId { get; set; }
}

Entity Framework sa implicitamente di mappare BarId in Bar.Id , consentendo così di assegnare proprietà di navigazione durante il caricamento lento.

In definitiva non è una buona pratica in circostanze "normali", in quanto tutto ciò che realmente fa è aggiungere confusione, e quindi ha un impatto negativo sulla leggibilità (in generale).

Tuttavia, potrebbero esserci altre considerazioni, altre forze trainanti che potrebbero portare al codice con questo tipo di denominazione. Ad esempio, alcuni strumenti si basano su convenzioni di denominazione (e su una sorta di capacità di riflessione / introspezione) per generare codice di tipo standard tra due sistemi collaborativi. È nello spirito dell'approccio della "convenzione sulla configurazione". La cosa più semplice da fare è fare in modo che i corrispondenti campi / proprietà abbiano lo stesso nome, ed è spesso utile averli in modo univoco per identificare il loro tipo genitore (o tabella, o qualsiasi altra struttura di livello superiore che ci sia), così da non Devo controllare tutto il tempo. Inoltre, mentre le convenzioni di denominazione variano tra sistemi, lingue e tecnologie, è necessario elaborare un approccio unificato qui, in modo che il risultato finale non segua le migliori pratiche OOP.

Questo era solo un esempio, ma come puoi immaginare, mentre le persone escogitano nuovi strumenti e tecnologie, sorgono tutti i tipi di fattori di parole reali che possono portare a queste partenze dalla "norma".

Ovviamente, c'è sempre l'altro lato della medaglia, ea volte le persone scrivono un codice simile a questo senza averne davvero una buona giustificazione.