18

Mi chiedevo se esistono buone pratiche o convenzioni per strutturare i tuoi progetti iOS?Esistono buone pratiche o convenzioni per la struttura del progetto ios

Grazie.

+0

Questo è un po 'vago, motivo per cui non penso che nessuno abbia ancora risposto. Intendi i file reali nel progetto e le directory in cui entrano? Intendi l'architettura del codice? Ecc. –

+0

@quixoto - Sono principalmente preoccupato su come gestire file diversi in diverse directory. – itsaboutcode

risposta

13

So che questa è una domanda vecchia, ma ho pensato di aggiungere una risposta per aiutare gli altri che atterrano qui.

Ho trovato utile this link.

9

Tratto da iOS Coding Best Practices Slideshare da Jean-Luc David:

enter image description here

+2

Dipende assolutamente da quanto codice hai nel tuo progetto, ma personalmente penso che una cartella denominata "Helpers" non sia buona. C'è il rischio che tutto alla fine finisca lì dentro, finché è considerato come una "utilità". Penso che le cartelle separate con i nomi autoesplicativi per il tipo separato di utilità siano migliori, come "Crittografia", "Serializzazione" ecc. –

+1

Un Helper/Utility-Package è un approccio comune per estrarre funzionalità che è riutilizzabile ed è più probabile che sia essere inserito in una libreria di utilità riutilizzabile un giorno. Ovviamente ci sono delle cartelle auto-esplicative all'interno di Helper/Utility-Package ma non consiglierei di metterle sullo stesso livello come il tuo pacchetto Model o Controller, specialmente in un grande progetto ... Ma dato che è tutto una questione di gusti, è molto importante essere d'accordo con la tua squadra su una struttura di base con cui tutti ti senti a tuo agio. –

4

Per quanto mi riguarda, Architecting iOS Project soluzione funziona perfettamente. Ho anche aggiunto Cocoapods.

Ora il mio progetto si presenta come:

enter image description here

0

Anche se sono d'accordo che la pratica più comune è quello di avere i file raggruppati per tipologie (ad esempio ViewControllers, modelli, ecc), vorrei aggiungere che ci sono alcuni affari casi in cui è più utile organizzare il codice con la funzionalità fornita. Ad esempio, se lavori per un'azienda che offre più servizi, ad esempio: AddressBook, Messaggi, Gestione documenti, ecc ...

Nei miei progetti di solito ho un cartella chiamata Common dove metto cose che riuso spesso, come aiutanti datetime, scrittori di IO ecc ... Altre cose che separo per funzionalità.

0

Seguiamo una struttura di progetto standard in modo che il team possa capire in un modo migliore.

enter image description here

1

ho usato uno simile a quanto segue per i miei progetti.

Ma dopo aver esaminato questo thread e alcuni altri articoli online, ho deciso di categorizzare alcuni tipi con una nuova UI di codice cartella.

  • Application (file Config con costanti, AppDelegate)
  • modelle
  • UI
    • Visualizzazioni
    • Controllers
    • Se uso file pennino (.XI ter) dovrebbero venire sotto questo altrimenti i storyboard (s)
  • Resources (Tutte le risorse come immagini, font personalizzati, file audio con ciascuno in diverse sottocartelle)
  • Servizi
  • Helpers/Utilità
  • biblioteche

Ma se si utilizza l'architettura MVVM, si prega di personalizzare questo t o il tuo miglior adattamento

Cheers!

Problemi correlati