Ciao,
nel tuo caso, dato che possiedi già le classi C#, è più indicato l'approccio definito code-first che ti permetterà di creare un database e le sue tabelle in conformità alle classi di quel modello.

Segui questo corso della Microsoft Virtual Academy che ti guiderà passo passo.
http://www.microsoftvirtualacademy.com/training-courses/implementing-entity-framework-with-mvc
Nel secondo capitolo vedrai come creare il DbContext, che è la classe che ti permetterà di decidere come mappare classi a tabelle poi di compiere le operazioni CRUD sui dati.

Quello che stavi sperimentando tu, invece, è l'approccio "model-first", che è consigliato a chi vuole creare il modello in maniera visuale, avvalendosi del designer offerto da Visual Studio. Grazie ai template .tt, le entità create nel designer vengono poi convertite in classi C#.
A te ovviamente il designer e i template .tt non servono perché le classi le hai già e non hai bisogno di progettarle di nuovo o di generarle dinamicamente.

giuseppe500 ha scritto:

Sono riuscito invece a creare un class diagram ma non so se possa servire.

No. Le relazioni vanno mappate per mezzo del DbContext di cui ti parlavo prima e del suo metodo OnModelCreating. Con questo approccio non si usano editor visuali, ma solo codice.

Tieni presente che qualche modifica alle tue classi è probabile che tu debba farla, soprattutto per supportare le relazioni.
Inoltre, è obbligatorio che le classi di entità abbiano una proprietà che viene usata come chiave primaria, altrimenti Entity Framework non potrà lavorarci (non saprebbe come distinguerle senza un valore che le contraddistingua univocamente).

ciao,
Moreno

Ciao Giuseppe,

giuseppe500 ha scritto:

Login failed for user 'Lenovo-PC\Giuseppe'.

Vuol dire semplicemente che la connection string non ha funzionato, perché non è stato possibile autenticarsi a Sql Express per accedere al db ifcClasses.DbIfc usando il tuo account di Windows.

Non ti so dire con precisione quale sia la causa. Potrebbe essere che l'autenticazione basata su account Windows non sia stata abilitata nella tua istanza di Sql Express oppure che il tuo utente di Windows (Lenovo-PC\Giuseppe) non abbia privilegi per accedere al database ifcClasses.DbIfc.

A proposito, hai già creato il database ifcClasses.DbIfc nella tua istanza di Sql Express, usando magari il programma Sql Server Management Studio?

giuseppe500 ha scritto:

so poco di sql server lo anticipo.

Ok. Prima di consigliarti di smanettare con db e privilegi, proviamo a modificare leggermente la tua connection string. Vediamo se il problema si risolve con questa modifica minima.

Ho sostituito Initial Catalog con AttachDbFileName perché così il database verrà collegato all'instanza di Sql Express all'avvio dell'applicazione, con tutti i privilegi necessari a far accedere il tuo utente di Windows.
Il file ifcClasses.DbIfc.mdf devi averlo aggiunto all'interno della cartella App_Data (se la tua è un'applicazione web) o nella cartella dell'eseguibile (se è un'applicazione per Windows).
Aggiungere un file mdf è semplice: dal Solution Explorer fai tasto destro su una cartella e clicca Aggiungi > Nuovo Elemento > Database Sql Server.

giuseppe500 ha scritto:

Poi sempre col generatore ho creato un dbcontext xon tutte le classi cosi:

1300 classi sono una bella quantità, non è corretto creare un solo DbContext per tutte quante. Non dico che non sia possibile (bisogna vedere le performance) ma si chiama Dbcontext non a caso. Tutte quelle classi apparterranno sicuramente a vari contesti, come vedo dalla pagina Wikipedia di ifc (che non conoscevo). Ci sono classi che riguardano costruzioni, prodotti, processi, partecipanti, fasi e così via.
Dividerle in contesti più piccoli sembrerà un lavoraccio inizialmente ma poi ti ritroverai con vari modelli più gestibili con cui si può iniziare a lavorare.

Non so se volevi realizzare un'applicazione orientata ai dati costruita in maniera completamente dinamica ma, se così non fosse, la suddivisione in contesti è un'attività che non puoi/devi evitare.

giuseppe500 ha scritto:

ho pensato anche di suare mongo db per semplificare ma chiedo a voi se un idea del genere è possibile o è una pura fantasia alla fine.

Ricorda che non dovresti ripiegare su una tecnologia solo perché sembrano esserci difficoltà con quella che avresti preferito usare. Se scegli MongoDb è perché in questa situazione ha dei vantaggi e perché si adatta meglio al modello. Mi sembra che tu qui abbia dei dati ben strutturati e quindi - ad una prima occhiata - sembra più adatto un database relazionale come Sql Server.

Ma potrei sempre sbagliarmi, eh, io non so come sono fatte le classi.
Se delle 1500 classi solo poche hanno un'identità (mentre la maggior parte è composta da Value Objects) allora probabilmente valuterei anche MongoDb per memorizzare e leggere interi documenti anziché essere costretto a fare innumerevoli JOIN per ricostruire un grafo molto ramificato.

ciao,
Moreno

---

Modificato da BrightSoul il 15 agosto 2015 10.45 -

ciao Giuseppe, prego!

I namespace XML non dovrebbero essere un problema perché il tool xsd.exe dovrebbe averti generato delle classi e delle proprietà decorate con gli attributi XmlRoot e XmlElement che recheranno, appunto, il namespace degli elementi XML con cui il deserializzatore si troverà a lavorare.
Guarda questa domanda:
http://stackoverflow.com/questions/465825/how-to-deserialize-an-xml-doc-with-a-prefixed-namespace-but-no-ns-prefixed-eleme
Nella risposta accettata trovi la classe prodotta da xsd.exe. Quegli attributi sono indicazioni utili per il deserializzatore XmlSerializer di cui trovi un esempio nella documentazione.
https://msdn.microsoft.com/it-it/library/he66c7f1(v=vs.110).aspx

giuseppe500 ha scritto:

system.xml.schema

Dipende da come vuoi usarlo. Se intendi modificare l'XSD, considera che è esso stesso un file XML quindi potresti manipolarlo anche con le classi XmlDocument o XDocument.
Ma potrebbe non servire se ti sei generato le classi con xsd.exe.

ciao,
Moreno

ciao,
ok, allora puoi caricare il file XML usando (per esempio) la classe XmlDocument e modificare i namespace come vedi in questo esempio:
https://msdn.microsoft.com/en-us/library/bdc390xe(v=vs.110).aspx
Risalva il documento, così che poi, quando verrà letto dall'XmlSerializer, abbia i namespace corretti, che si aspetta di trovate.

In alternativa, dato che esiste un overload del metodo Deserialize dell'XmlSerializer che accetta un XmlReader, potresti crearti una tua implementazione personalizzata di XmlReader che, quando è il momento di leggere il valore di un namespace, restituirà il namespace corretto e non quello effettivamente trovato nel file XML.
Questa è una soluzione più elegante rispetto alla precedente perché non ti costringe a caricare->modificare-risalvare il file, ma ti permette di riscrivere i namespace al volo.
Soltanto che non l'ho mai fatto, e quindi non ti so dare esempi di codice.
Probabilmente dovrai fare almeno l'override di ReadAttributeValue ma non ti so dare indicazioni più precise.

ciao,
Moreno