¿Cuál es la forma estándar de organizar el código de iPhone MVC en XCode?

Question

Tengo una aplicación de iPhone que contiene varias vistas y sus controladores asociados. Al observar el código de ejemplo, he visto diferentes maneras de organizar estos archivos: agrupar todas las vistas, agrupar todos los controladores o agrupar las vistas y los controladores por funcionalidad.

Opción 1 - Vistas y controladores agrupan por separado

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

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

Opción 2 - Los artículos agrupados por funcionalidad

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

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

Opción 1 parece que tiene más sentido desde el punto de vista MVC - la El código está agrupado, pero me pregunto a medida que la aplicación crece a más de 10 vistas y controladores, ¿es el más lógico y fácil de mantener? ¿Hay alguna recomendación de mejores prácticas al respecto? Actualmente, seré el único que mantendrá la aplicación, pero si habrá o no habrá varios desarrolladores, quiero utilizar las mejores prácticas tanto como sea posible. ¿Hay estándares publicados sobre esto?

Answer 1

Estoy trabajando en un gran proyecto xCode en este momento. No es para iPhone, pero no creo que importe por el diseño de la estructura de archivos :)

Comencé con la opción # 1 y luego pasé a algo así como la opción # 2 cuando el número de archivos aumentado. Tiendo a agrupar cosas por "interfaces", es decir, todas las fuentes asociadas con un área particular de funcionalidad dentro de la aplicación, y luego crear subgrupos para secciones más grandes si es necesario.

En cuanto a nomenclatura va, yo prefiero para identificar Modelo, Vista y Controlador usando tan poco nombre de la clase de bienes raíces como sea posible, por lo que mis nombres de las clases tienen un aspecto similar a:

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

Esto todavía permite una comprobación visual rápida para ver el tipo de una clase (M, V o C) pero deja más espacio para la parte descriptiva del nombre.

También he encontrado que es útil para especificar algunas clases que no encajan en el patrón MVC (jadeo!):

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

De todos modos, eso es ya más información que usted pidió, pero yo encontrar el problema de nomenclatura relevante para el problema de diseño, ya que la verdadera pregunta es: ¿cuál es la mejor manera de organizar mi código para un gran proyecto de xCode?

Espero que ayude.Así es como se ve cuando se juntan:

[+] 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 veces la mejor práctica es hacer lo que más le parezca. Personalmente, me gusta la agrupación por funcionalidad, pero de cualquier manera puede volverse difícil de manejar si no se tienen en cuenta los nombres significativos y los nombres de refactorización cuando ya no describen la funcionalidad.

Answer 3

No sé si hay una organización estándar en XCode, especialmente porque la organización de proyectos dentro del IDE a menudo no se traduce a la organización de archivos en el disco.

Dicho esto, suelo hacer algo similar a su Opción 1, sin más motivo que el que se asemeja más a la estructura de carpetas en Rails, que es a lo que estaba acostumbrado cuando comencé a jugar con el iPhone.

Answer 4

La segunda opción tiene más sentido a medida que su proyecto crece.

Además, el proyecto predeterminado tiene archivos xib en "recursos", pero de nuevo a medida que un proyecto crece, tiene mucho más sentido mover archivos relacionados a un grupo lógico para una pantalla u otra funcionalidad.

Una agrupación por modo de ejemplo sería:

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) 

El delegado de la aplicación podría pasar el rato en utilitites, o tal vez simplemente flotando por encima de todos los grupos dentro de las clases.

Answer 5

La opción 2 tiene más sentido para mí. Piénselo, mientras está codificando, siempre editando alrededor de la "vista" y su controlador, la opción 2 hace que encuentre los archivos apropiados de la manera más eficiente.

Answer 6

Consulte el siguiente enlace. Espero eso ayude !

http://akosma.com/2009/07/28/code-organization-in-xcode-projects/ (Tenga en cuenta "Estructura Conclusión" en este enlace - Al final de este enlace)

Answer 7

La estructura de carpetas estándar MVC Xcode es el siguiente.

1. CoreData: contiene clases de DataModel y Entity.

2. Extensión: Contener Una clase (extensiones de clase de manzana por defecto + extensiones de clase de proyectos.)

3. Ayudante:. Contener clases de Terceros/Marcos (. Ej SWRevealController) + clases de transición (por ejemplo, la clase Obj C en Swift proyecto basado)

4. Modelo: Cree una clase singleton (p. ej., ModeloApp - NSArray, NSDictionary, String, etc.) para guardar datos. El análisis de la respuesta del servicio web y el almacenamiento de datos también se realiza aquí.

5. Servicios: contienen procesos de servicio web

6. Ver (por ejemplo Login Verificación, solicitud/respuesta HTTP.): Contener storyboard, Clases LaunchScreen.XIB y View. Hacer una Cells carpeta sub - contener UITableViewCell, UICollectionView celular etc.

7. controlador: Contener Logic o código relacionado con UiElements (por ejemplo, la referencia de UIButton acción + se hace clic.)

Consulte:

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

Nota: He mencionado las clases AppModel y AppController (Son clases singleton como AppDelegate)