Qual è il modo standard per organizzare il codice MVC di iPhone in XCode?

Question

Ho un'applicazione per iPhone che contiene diverse viste e i relativi controller associati. Guardando al codice di esempio, ho visto diversi modi per organizzare questi file: hanno tutte le viste raggruppate, quindi tutti i controller raggruppati o raggruppano le viste e i controller in base alla funzionalità.

Opzione 1 - Visualizzazioni e controller raggruppati separatamente

-Views 
    | 
    - EditItemView.h 
    - EditItemView.m 
    - AddItemView.h 
    - AddItemView.m 

-Controllers 
    | 
    - EditItemViewController.h 
    - EditItemViewController.m 
    - AddItemViewController.h 
    - AddItemViewController.m 

Opzione 2 - I prodotti raggruppati per funzionalità

-AddItem 
    | 
    - AddItemViewController.h 
    - AddItemViewController.m 
    - AddItemView.h 
    - AddItemView.m 

-EditItem 
    | 
    - EditItemViewController.h 
    - EditItemViewController.m 
    - EditItemView.h 
    - EditItemView.m 

Opzione 1 sembra avere più senso dal punto di vista MVC - il il codice è raggruppato insieme, ma mi chiedo come l'app cresca a oltre 10 visualizzazioni e controller, è quella più logica e manutenibile? Esiste una raccomandazione sulle migliori pratiche in merito? Al momento, sarò l'unico a mantenere l'app, ma anche se ci saranno o meno sviluppatori, voglio usare le migliori pratiche il più possibile. Ci sono standard pubblicati su questo?

Answer 1

Attualmente sto lavorando a un grande progetto xCode. Non è per l'iPhone, ma non credo che le cose per il bene di aspetto di struttura del file :)

ho iniziato con l'opzione # 1 e poi si trasferì a qualcosa come opzione # 2, quando il numero di file è aumentato. Tendo a raggruppare le cose per "interfacce", cioè tutte le fonti associate a una particolare area di funzionalità all'interno dell'applicazione, e quindi creare sottogruppi per sezioni più grandi, se necessario.

Per quanto riguarda la denominazione va, preferisco identificare Model, View Controller e con il minor nome della classe immobiliare possibile, quindi i miei nomi di classe sono simili a:

AM_DillPickle // model class 
AV_Sasquatch // view class 
AC_DirtBike // controller class 

Questo consente ancora per un rapido controllo visivo per vedere il tipo di una classe (M, V o C) ma lascia più spazio per la parte descrittiva del nome.

ho anche trovato utile specificare alcune classi che non rientrano nel modello MVC (gasp!):

AU_Helper  // utility class (text formatting, high-level math, etc.) 
AD_Widget  // device class (used to represent hardware drivers) 

Comunque, questo è già più informazioni di quelle che hai chiesto, ma io trova il problema di denominazione come rilevante per il problema del layout, poiché la vera domanda è: qual è il modo migliore per organizzare il mio codice per un grande progetto xCode?

Spero che aiuti.Ecco come appare quando vengono messi insieme:

[+] Project 
    [-] Target One 
    [+] Target Two 
     [-] Preferences 
     [-] Login 
     [+] Main Window 
      # MainWindow.XIB 
      # AC_MainWindow.h 
      # AC_MainWindow.m 
      # AC_DisplayScreen.h 
      # AC_DisplayScreen.m 
      [-] Home Screen 
       # HomeScreen.XIB 
       # AC_HomeScreen.h 
       # AC_HomeScreen.m 
       # AV_FancyDisplay.h 
       # AV_FancyDisplay.m 
      [+] Widget Screen 
      [+] Other Screen 

Answer 2

A volte la pratica migliore è fare ciò che più ha senso per voi. Personalmente mi piace il raggruppamento per funzionalità, ma in entrambi i casi può diventare ingombrante se non si pensa a nomi significativi e nomi di refactoring quando non descrivono più la funzionalità.

Answer 3

Non so che ci sia un'organizzazione standard in XCode, soprattutto perché l'organizzazione del progetto all'interno dell'IDE spesso non si traduce nell'organizzazione di file su disco.

Detto questo, di solito faccio qualcosa di simile alla tua Opzione 1, per nessun motivo migliore di quello che più assomiglia alla struttura delle cartelle in Rails, che è quello a cui ero più abituato quando ho iniziato a scherzare con l'iPhone.

Answer 4

La seconda opzione ha più senso quando il progetto cresce.

Inoltre, il progetto di default ha file xib andare in "risorse", ma di nuovo come un progetto cresce ha molto più senso spostare i file correlati in un gruppo logico per qualche schermo o altra parte di funzionalità.

Una disposizione raggruppamento a titolo di esempio potrebbe essere:

3rdParty (for something like regex) 
Utilities (for category additions to classes like UITableViewCell) 
Tab1Classes 
--Screen1 
--Screen2 
Tab2Classes 
Tab3Classes 
Data (for holding plists or other data you may want to load during an app run) 
Resources (still here for random images it makes sense to keep central) 

Il delegato App potrebbe bloccarsi in utilitites, o forse solo galleggiante sopra tutti quei gruppi nelle classi.

Answer 5

L'opzione 2 ha più senso per me. Pensateci, mentre state codificando, modificando sempre attorno alla "vista" e al suo controller, l'opzione 2 vi fa trovare i file appropriati nel modo più efficiente.

Answer 6

Fare riferimento al seguente link. Spero che sia d'aiuto !

http://akosma.com/2009/07/28/code-organization-in-xcode-projects/ (Si prega di notare "Conclusione Struttura" in questo link - Alla fine di questo link)

Answer 7

La struttura delle cartelle standard di Xcode MVC è la seguente.

1. CoreData: contiene classe DataModel ed entità.

2. Estensione: Contenere Una classe (estensioni classe mela di default + estensioni classe progetto).

3. Helper:. Contenere le classi terze parti/Frameworks (es. SWRevealController) + classi Bridging (ad esempio classe Obj C a Swift progetto basato)

4. Modello: creare una classe singleton (ad es .AppModel - NSArray, NSDictionary, String ecc.) per il salvataggio dei dati. Anche l'analisi e la memorizzazione dei dati di risposta del servizio Web viene eseguita qui.

5. Servizi: contengono processi Web Service

6. Vista (ad esempio accesso di verifica, richiesta HTTP/Response.): Contenere storyboard, LaunchScreen.XIB e classi di visualizzazione. Fare un sub Cells cartella - contenere UITableViewCell, UICollectionView cellulare ecc

7. Controller: contenere la logica o codice relative al UIElements (ad esempio, il riferimento di UIButton + cliccato azione.)

riferimento:

https://github.com/futurice/ios-good-practices#common-libraries http://akosma.com/2009/07/28/code-organization-in-xcode-projects/

Nota: ho menzionato le classi AppModel e AppController (Sono classi singleton come AppDelegate)