51 messaggi dal 17 maggio 2011
Ciao a tutti, vi espongo due casi in cui mi piacerebbe confrontarmi con voi.
class a{
  public marca ma;
  public modello mo; 

  public int dato1;
  public int dato2;
}

poniamo il caso che:
marca_id = 1 e modello_id = 1 sia obbligatorio il dato1
marca_id = 1 e modello_id = 2 sia obbligatorio il dato2
e così via.

Ho ragionato sull' estensione
classe b:a{
public int dato1;
}
classe c:a{
public int dato2;
}

Domanda n°1)Ma essendo marca e modello a sua volta entità non mi sembra sia gestibile la cosa.

Poi vorrei avere un vs. consiglio
Per fare in modo che i dati sia configurabili all'interno dell'applicazione mi hanno fatto implementare questo :
class instrument{
  public Model m;
...
  public virtual ICollection<ParameterInstrument> ParameterInstruments { get; set; }
}

class Model{
    ....
        public virtual ICollection<ModelParameter> ModelParameters { get; set; }
}

class ModelParameters{
  public virtual Model Model
  public virtual Parameter Parameter  
  
  public bool Required
  public int? MinValue  //se parameter è int può avere un valore minimo
  public int? MaxValue
  public int? Len      //se parameter stringa può avere una lunghezza massima
}

class Parameter{
  public string name
  public TypeValue //Enumerato che mi dice se intero stringa data eccecc, lascio perdere nel caso sia un enumerato
  ...
}

public class ParameterInstrument

  public string Value { get; set; }

  public virtual Instrument Instrument { get; set; }

  public virtual Parameter Parameter { get; set; }

}

In pratica instrument ha un model
Il model ha una serie di parameter (ModelParameter) che descrive i capi di cui è composto.
di per se il modelparameter dice che uno specifico Parameter (ad esempio SerielNumber che è di TypeValue String) può essere o non obbbligatorio (Required) e può avere una Len massima.
Infine ParameterInstrument contiene in Value il valore dell'effettivo model parameter.

Sono un pò contro a questa tecnica perchè sono costretto:
1- memorizzare tutti i valori all'interno di un campo string e poi andare a recuperare i dettagli del tipo di parametro per gestirlo.
2- se voglio recuperare i dati di un determinato strumento ho n tuple per ogni parameter.
3- eseguire continui cast dei dati per stamparli e memorizzarli
4- il modelstate di mvc non serve a niente, devo effettuare tutti i controlli a manima in base a come è configurato il modelparameter.
Potrei continuare all'infinito

Note positive:
1- possono creare i parametri che vogliono per ogni strumento....

Domanda n°2) siete pro o contro verso una soluzione del genere?
avreste risolto la questione in modo diverso?
Modificato da fractals87 il 20 marzo 2019 10:33 -
11.857 messaggi dal 09 febbraio 2002
Contributi
Ciao,
ho lavorato anch'io a un progetto simile. Nel mio caso erano frigoriferi ma erano comunque composti di più moduli, ciascuno configurabile con una pletora di parametri.

Non c'è stata la possibilità ma avrei voluto sperimentare con un database documentale, dal momento che i dati erano - per loro natura - non strutturati. Questo significa rinunciare ad usare Entity Framework, almeno per la parte che riguarda la configurazione dei parametri. Le informazioni di testata (nome del modello, data di immatricolamento, ...) le puoi comunque tenere in un db relazionale.

Se usi SQL Server 2016 hai il vantaggio che puoi tenere sia dati strutturati che non strutturati sulla stessa riga, grazie al supporto del JSON. Ovviamente le query le puoi fare anche nei confronti delle proprietà che si trovano nel documento JSON.
https://docs.microsoft.com/it-it/sql/relational-databases/json/json-data-sql-server?view=sql-server-2017

Poi la soluzione più adatta dipende molto dal tipo di applicazione che stai visualizzando. Se hai molti utenti che leggono i dati, sarà una fatica per il DB tirar fuori tutte le informazioni che ti permetteranno di ricostruire l'intero grafo di oggetti. Per abbassare il costo dell'applicazione (leggi: per farla funzionare con meno risorse hardware) potresti predisporre un modello pensato appositamente per la lettura. Ad esempio, l'intero grafo di oggetti lo puoi salvare come documento JSON in Sql Server o in MongoDb a mo' di cache. Ma ogni volta che i dati cambiano, avrai l'onere di tenerlo aggiornato per evitare che i tuoi utenti visualizzino dati obsoleti. Più lavoro per te ma meno lavoro per le macchine (e meno spesa per il cliente, consentendo a te di avere più margine).

ciao,
Moreno

Enjoy learning and just keep making

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.