Linee guida di progettazione per questo scenario in C #?

1. Gli oggetti che contengono molti altri oggetti probabilmente stanno facendo troppe cose.
2. Richiedere al programmatore di specificare le dipendenze li costringe a ripetersi, il che porterà a errori / incongruenze. Se riesci a trovare un modo per rilevare le dipendenze (staticamente o dinamicamente), sarebbe meglio.
3. Avere un fascio di dipendenze mi preoccupa che le tue astrazioni non siano così pulite come dovrebbero essere. Le dipendenze tra le variabili dovrebbero (idealmente) essere isolate all'interno di una classe. Questo potrebbe non essere applicabile nel tuo caso, ma come linea guida - assicurati di aver davvero bisogno di un accoppiamento stretto tra le variabili in classi diverse.

E tutto ciò detto, la struttura compatta ha dovuto fare la convalida dell'input per sempre. Anche se le annotazioni di dati non sono supportate, è probabile che questo sia un problema risolto.

Che ne dici di estrarre la convalida e metterla allo stesso livello dell'input?

Quello che voglio dire è che non è il ruolo di un oggetto che si convalida . Un oggetto dovrebbe sempre essere valido: la creazione di uno non valido non ha molto senso. Allo stesso modo, non crei una persona con un'età di -50 , perché un'età è sempre un valore positivo o pari a zero.

Per garantire che un oggetto sia valido, uno utilizza contratti di codice in .NET Framework. Gli invarianti sarebbero particolarmente utili, dal momento che non solo impedirebbero di creare un oggetto non valido, ma anche di alterarne uno valido in modo che non fosse più valido. Allo stesso modo, i vincoli nei database impediscono l'archiviazione dei dati non validi.

Quindi, trovare un posto per la convalida dell'input dipenderà dal contesto. Se l'oggetto viene creato dall'input dell'utente (incluso, ad esempio, un'applicazione che utilizza la tua API), convalida l'input. Altre situazioni attenuerebbero la convalida da qualche altra parte. Se la creazione di un oggetto è un'attività difficile, verrà utilizzato uno factory , che descriverà come creare un oggetto, senza violare i suoi contratti.

Penso che ci sia un errore che stai facendo. E tu vuoi creare direttamente un framework / libreria. Per esempio. non si conoscono tutti i casi che questo framework / libreria deve risolvere, tuttavia, si sta tentando di creare questo framework / libreria.

Dovresti prima fare le cose direttamente, senza prima creare un quadro. Solo dopo aver creato più casi dovresti provare ad astrarre ciò che è comune tra quelle classi. Cercare di essere "dinamico" e "universale" ti farà solo del male a lungo andare.

Inoltre, il tuo esempio di codice sta urlando da un cattivo design OO. Nel momento in cui dai un enum "type" o "kind" (o "category" nel tuo caso), diventa ovvio che dovrebbero essere più classi diverse all'interno di una gerarchia. Questo è probabilmente il motivo per cui il tuo codice sembra così cattivo e "statico". Perché non ti importava della giusta separazione tra preoccupazioni e polimorfismo. Se lo facessi, potresti anche renderti conto che non hai bisogno di alcuna convalida dinamica e che la convalida con codice a mano va bene.

Bene, se vuoi liberarti di queste istruzioni switch è una buona idea usare il polimorfismo per convalidare gli oggetti (ad esempio rendendo MyBigClass una classe che è supertipo per le tue marche di veicoli).

I vantaggi di questo approccio sono:

1. Puoi utilizzare l'invio dinamico per metodi come validare che sono astratti a MyBigClass Level e sono implementati nelle classi specifiche (Toyota, Mercedes, ...) che estendono MyBigClass
2. Le regole per ciascun tipo di veicolo sono incapsulate

È possibile specificare un'interfaccia, ad esempio IValidatable e utilizzare reflection per scorrere tutte le proprietà e le proprietà secondarie e convalidare le eventuali implementazioni dell'interfaccia. È quindi necessario implementare Validazione su ogni piccola proprietà secondaria.

Many of the properties are dependent on each other means they have some sort of dependencies.

Questa è la radice del tuo problema però. Avere qualcosa che è difficile da validare è solo il sintomo. Il tuo miglior risultato è dividere la tua classe in componenti più piccoli e più gestibili.

Penso che tu voglia qualcosa come Fluent Validator per ASP MVC

L'idea è la stessa delle annotazioni, ma puoi definire regole in fase di runtime, anche se con meno "istruzioni if".

Ecco il codice di esempio del metodo di convalida:

[Validator(typeof(PersonValidator))]
public class Person {
    public int Id { get; set; }
    public string Name { get; set; }
    public string Email { get; set; }
    public int Age { get; set; }
}

public class PersonValidator : AbstractValidator<Person> {
    public PersonValidator() {
        RuleFor(x => x.Id).NotNull();
        RuleFor(x => x.Name).Length(0, 10);
        RuleFor(x => x.Email).EmailAddress();
        RuleFor(x => x.Age).InclusiveBetween(18, 60);
    }
}