Sto iniziando a lavorare con le librerie di classi nella mia classe C #. Ci è stato detto di scrivere codice che può essere usato più di una volta. Devo mantenere tutte le definizioni di classe in una libreria di classi per la durata del termine o separarle per progetto?
Separali per scopo. Una biblioteca di classe dovrebbe essere coesa. Non dovresti gettare cose arbitrarie insieme.
Ad esempio, ho appena scritto una libreria di aggiornamento. Ha classi che si occupano dell'aggiornamento di un'applicazione. Ma non ha classi per alcune operazioni di stringa pulite perché non ha senso aggiungerle. Ogni volta che voglio riutilizzare del codice, voglio riutilizzare solo una cosa (ad esempio questo aggiornamento). Se butti tutto insieme, sarà un disastro e costringerai anche te stesso a fare riferimento all'intera cosa quando vuoi davvero usarne una sola. Datti la libertà di riutilizzare le parti che desideri.
La scrittura di codice veramente riusabile è difficile , ma sicuramente ti incoraggio a provare a farlo. Imparerai cose importanti sulla scrittura del codice effettivamente riutilizzabile.
Suggerisco anche di leggere su YAGNI e KISS principi. Non seguire ciecamente, ma essere consapevoli di loro.
La maggior parte delle basi di codice aziendali che ho visto organizzano le loro classi in diversi progetti in base al loro scopo. Ad esempio, all'interno di una soluzione, potresti avere i seguenti progetti:
SampleSolution.Presentation (Cose dell'interfaccia utente)
SampleSolution.BusinessLogic (Regole aziendali / elementi logici)
SampleSolution.Persistance (Elementi relativi ai dati)
Ci sono molte varianti sul nome particolare dato alla libreria ... Per esempio, ho visto il progetto BusinessLogic chiamato Domain, BusinessRules, Business ... Dipende solo dalle tue preferenze. Ma la cosa principale è separare questi elementi rende le cose più manutenibili e logiche - è molto più facile trovare rapidamente la classe che stai cercando. A seconda del modo in cui l'app viene sviluppata, potrebbero esserci anche librerie aggiuntive come modelli, viste, controller, DTO (oggetti di trasferimento dati) e così via.
A seconda della natura dei tuoi compiti, può o non ha senso separarli in questo modo. Ad esempio, se stai scrivendo alcune classi che fanno cose come manipolare stringhe, o eseguire calcoli - quelli che rientrano in un tipo di "utilità" di categorizzazione - sarebbe molto sensato metterli tutti in uno biblioteca di classe. In questo modo, nei futuri incarichi, puoi semplicemente fare riferimento alla DLL compilata, che è il modo in cui normalmente utilizzi le librerie di terze parti.
Uso le librerie di classi effettive (ad es. le DLL) per scopo / architettura, quindi separo ulteriormente quelle che utilizzano cartelle e spazi dei nomi. Ad esempio in un'applicazione tipica potrei avere:
Wayne.MyApplication.Domain (Business objects)
Wayne.MyApplication.Core (Common things required by everything else)
Wayne.MyApplication.UI (Interface)
e quindi dividerli ulteriormente (ad esempio, il mio progetto Domain contiene cartelle per modelli, repository e servizi). Una cosa di cui diffidare è il "DDD Anti-pattern" con il quale si ha un progetto separato per gli oggetti Dominio, DTO, Repository, Servizi, Specifiche, ecc. Ecc. Ecc. Quando questi sono logici separazioni, non fisiche.
Leggi altre domande sui tag c# programming-practices libraries