Class Naming Conundrum

Question

Class Naming Conundrum

#1 da (9 voti)

5

Sto lavorando a un progetto personale che funziona con i database, e in questo progetto ho un insieme di classi che sono simili , quindi ereditano da una classe base comune. Il problema che ho di fronte è che ho la sensazione fastidiosa che i nomi delle classi che derivano dalla classe base non riflettano realmente quello che sono in realtà.

Avvertenza: Si prega di ignorare il fatto che questa sembra una reinvenzione della ruota. Questo è il punto del progetto.

La classe base comune è chiamata Entità. Il suo scopo è quello di servire come base per:

Classi che descrivono i dati restituiti da una query SQL o stored procedure o
Classi che descrivono una query SQL o una stored procedure e i relativi parametri.

Entrambe queste classi sono create dai consumatori dell'assembly per descrivere le stored procedure e le query nel loro database e i dati che recupereranno da esso.

Ad esempio, questi sono progettati per funzionare contro il database Northwind:

public class Employee : DataEntity
{
    public int EmployeeId { get; set; }
    public string LastName { get; set; }
    public string FirstName { get; set; }
}

[Sql(@"SELECT [EmployeeId], [LastName], [FirstName] 
       FROM [Employees] 
       ORDER BY [LastName], [FirstName]")
public class SelectEmployee : SqlEntity
{
    public int EmployeeId { get; set; }
}

Allo stato attuale, attualmente sto chiamando la prima di queste entità di dati e le seconde entità SQL. Tuttavia, non sono del tutto sicuro che questi siano termini adatti. Ad esempio, sono in realtà modelli ? C'è un termine migliore che non sto considerando?

L'assembly considera solo le proprietà pubbliche che hanno sia un getter che un setter. Lo sviluppatore può aggiungere qualsiasi altra cosa se è necessario. Quindi un'entità dati può essere estesa per includere funzionalità aggiuntive.

Qualsiasi consiglio sarebbe molto apprezzato.

Modifica

Vale la pena notare che puoi anche modellare le stored procedure con questa roba (di nuovo, usando una procedura memorizzata nel database Northwind):

[Sql()]
public class CustOrderHist
{
    [Parameter("@CustomerId", SqlDbType = SqlDbType.NChar, MaxLength = 5)]
    public string CustomerId { get; set; }
}

L'assembly associa automaticamente le classi alle stored procedure e le proprietà ai parametri.

design c# naming-standards

posta Mike Hofer 10.06.2013 - 15:59

fonte

1 risposta

Leggi altre domande sui tag design c# naming-standards

SOA è un'utopia? [chiuso] C # Algoritmi per * Operatore

score 9 · Accepted Answer

Quando si nominano le classi è spesso allettante includere parole che descrivono l'utilizzo in termini di programmazione. Queste parole potrebbero includere abstract , entity e / o base . Così finisci per creare classi come AbstractOffice o BaseOffice . Il nome della classe implica due significati su cosa fa Office e come viene utilizzato Abstract . Non consiglio di farlo. Aggiunge ulteriori dettagli nel nome che non è necessario.

KISS (Keep it Simple Stupid)

Recentemente ho rifattorizzato un progetto che ho fatto un anno fa per usare nomi semplici, ed è diventato molto più facile leggere il codice. Fare un tentativo e vedere se aiuta. Puoi sempre rinominare le classi più tardi.

public class Employee : Data
{
    public int Id { get; set; }
    public string LastName { get; set; }
    public string FirstName { get; set; }
}

[Sql(@"SELECT [EmployeeId], [LastName], [FirstName] 
   FROM [Employees] 
   ORDER BY [LastName], [FirstName]")
public class Employees : Query
{
    public int Id { get; set; }
}

Quando rimuovi i termini specifici della programmazione (cioè ho rimosso Select , Entity e rinominato Sql in Query ). Le lezioni diventano più leggibili. Ora il loro nome deduce solo informazioni specifiche (ad esempio si tratta di un dipendente). L'implementazione che utilizza SQL o rappresenta un modello di entità è irrilevante. Queste informazioni dovrebbero essere inserite nei commenti della classe, non nel nome.

In futuro, avrai un bug. Quale descrizione è più facile da capire e un risultato più facile da trovare nel codice sorgente.

Employee John Smith is not an active member of Employees.

o

EmployeeEntry John is not an active member of SelectEmployee

Questo è solo un esempio, ma in seguito, quando utilizzi queste classi, il codice diventa difficile da leggere. Un mare di termini che non sono pertinenti a ciò che sta facendo il codice.