Condivisione di classi o interfacce tra diversi progetti

Stavo cercando delle risposte in SO o qui, ma senza risultati, ecco perché te lo chiederei.

Supponiamo che io abbia due diversi progetti, ad esempio la parte server e la parte client di un'app. Sto sviluppando la mia parte, mentre il mio amico sta realizzando la seconda. Ma entrambi dovremmo usare alcune interfacce comuni come Usero AccountInfoo ChangableAccount... qualunque cosa per garantire una compatibilità. Ad esempio, se un client invia i dati di un utente al server, il server dovrebbe operare sulla stessa classe. Lo stesso vale per le interfacce, ecc. Inoltre, se ci sono cambiamenti in un'interfaccia comune, entrambi i progetti dovrebbero adattare il proprio codice alla nuova situazione.

L'unica soluzione che posso vedere ora è quella di creare un progetto in più in cui sono definite tutte le cose comuni. Noi, io e il mio amico, dovremmo aggiungere questo progetto come dipendenza a un progetto principale (client o server). Il progetto condiviso può essere gestito da un sistema di controllo della versione, quindi abbiamo sempre lo stato più aggiornato.

Quale altra soluzione suggeriresti? Come vengono risolti tali problemi nelle app professionali?

creare un progetto in più in cui sono definite tutte le cose comuni

Questo è esattamente il primo passo per condividere parti riutilizzabili - ed è la parte facile. La parte più difficile è decidere se i due progetti che utilizzano la libreria condivisa devono avere cicli di rilascio indipendenti (o meno) e se dovrebbe essere possibile che il "progetto A" usi la versione 1.0 della tua lib condivisa, mentre il progetto B usa versione 2.0 allo stesso tempo .

Se si desidera che quest'ultimo sia possibile, è necessario disporre di uno schema di controllo delle versioni rigoroso e della gestione delle versioni per la propria libreria (e numeri di versione come parte del nome del file della libreria, come suggerito da @RoryHunter). In questa situazione, dovresti anche occuparti della compatibilità con le versioni precedenti della tua libreria. La tua libreria dovrebbe essere gestita come un prodotto separato, aggiungendo unit test per assicurarsi che le diverse versioni in produzione siano una buona idea, e anche uno strumento come Maven può avere senso.

Se, tuttavia, vuoi prevenire quella situazione, dovresti gestire il "progetto A", il "progetto B" e la tua lib come un progetto comune, con un processo combinato di sviluppo, compilazione e rilascio. Ciò consentirà di modificare l'interfaccia comune della libreria condivisa molto più e spesso rispetto al primo scenario. E non avrai bisogno di qualcosa come Maven o numeri di versione nel nome del file della libreria. Ma il compromesso è che A e B non possono più essere sviluppati indipendentemente.

La tua soluzione è quella giusta Inserire il codice condiviso in un altro progetto che crea il proprio file JAR e utilizzarlo in entrambi i progetti. Quando si crea il file JAR, è possibile che si desideri includere la versione nel nome, ad esempio in stile Debian;

libmyproject-shared-1.0.jar

Non impedisce problemi di versioning, ma dovrebbe aiutare. Non ho mai usato Maven, ma capisco che può aiutare in questa situazione.

creare un progetto in più in cui sono definite tutte le cose comuni

Questo è esattamente il modo in cui .Net si aspetta che tu lo faccia.

Estrarre questi oggetti in un terzo assieme e fare riferimento a questo da entrambi i progetti. Suggerirei di farlo come interfacce, che è più pulito, ma ...

Fai attenzione alla serializzazione:

• L'unico modo in cui ho potuto serializzare / deserializzare direttamente gli oggetti tra i due programmi (è vero che qualche tempo fa usando Framework 2.0) era installare l'assembly "condiviso" nella Global Assembly Cache su macchine client e server. Se l'assemblaggio era "locale" per ciascun progetto, il Framework li vedeva come tipi discreti e si rifiutava di [de] serializzare l'uno nell'altro.
• E [de] serializzare oggetti digitati come interfacce è un po 'una "sfida". Il tipo originale, non di interfaccia, non sembrava "farcela" attraverso la "pipe" di serializzazione, quindi il destinatario non sapeva quale tipo concreto "costruire" dal flusso in entrata.

Come altri hanno suggerito, il tuo processo di pensiero è accurato. Professionalmente, la maggior parte userebbe qualcosa come Maven o Gradle per gestire queste dipendenze in modo efficiente.