2009-06-04 24 views
15

Tôi có một ứng dụng iPhone có chứa một số chế độ xem và bộ điều khiển liên quan của chúng. Nhìn vào mã mẫu, tôi đã thấy nhiều cách khác nhau để tổ chức các tệp này - hoặc có tất cả các khung nhìn được nhóm lại, sau đó tất cả các bộ điều khiển được nhóm lại, hoặc nhóm các khung nhìn và các bộ điều khiển theo chức năng.Cách chuẩn để tổ chức mã MVC iPhone trong XCode là gì?

Lựa chọn 1 - Số lượt xem và điều khiển nhóm riêng

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

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

Lựa chọn 2 - Mục nhóm lại theo chức năng

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

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

Lựa chọn 1 dường như có ý nghĩa hơn từ một quan điểm MVC - các mã được nhóm lại với nhau, nhưng tôi tự hỏi khi ứng dụng phát triển lên 10+ chế độ xem và bộ điều khiển, điều đó là hợp lý nhất và có thể duy trì? Có đề xuất thực hành tốt nhất nào về vấn đề này không? Hiện tại, tôi sẽ là người duy nhất duy trì ứng dụng, nhưng có hay không sẽ có nhiều nhà phát triển, tôi muốn sử dụng các phương pháp hay nhất càng nhiều càng tốt. Có tiêu chuẩn được công bố về điều này?

Trả lời

18

Tôi đang làm việc trên một dự án xCode lớn ngay bây giờ. Nó không phải dành cho iPhone, nhưng tôi không nghĩ rằng vấn đề vì cách bố trí cấu trúc tệp :)

Tôi bắt đầu với tùy chọn # 1 và sau đó chuyển sang thứ gì đó như tùy chọn # 2 khi số lượng tệp tăng. Tôi có xu hướng nhóm mọi thứ theo "giao diện", nghĩa là tất cả các nguồn được liên kết với một khu vực chức năng cụ thể trong ứng dụng và sau đó tạo các nhóm con cho các phần lớn hơn nếu cần.

As far as đặt tên đi, tôi thích để xác định Model, View và Controller sử dụng càng ít tên lớp bất động sản càng tốt, vì vậy tên lớp học của tôi trông giống như:

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

này vẫn cho phép một kiểm tra trực quan nhanh để xem loại của một lớp (M, V, hoặc C) nhưng nó để lại nhiều chỗ cho phần mô tả của tên.

Tôi cũng đã tìm thấy nó hữu ích để xác định một số lớp học mà không phù hợp với mô hình MVC (thở hổn hển!):

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

Dù sao, đó là đã có nhiều thông tin hơn bạn yêu cầu, nhưng tôi tìm thấy vấn đề đặt tên có liên quan đến vấn đề bố cục, vì câu hỏi thực sự là: cách tốt nhất để tổ chức mã của tôi cho một dự án xCode lớn là gì?

Hy vọng điều đó sẽ hữu ích.Dưới đây là cách mọi thứ trông giống nhau khi đặt cùng nhau:

[+] 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 
1

Đôi khi thực hành tốt nhất là làm những gì có ý nghĩa nhất đối với bạn. Cá nhân tôi thích nhóm theo chức năng, nhưng dù sao thì nó cũng trở nên khó sử dụng nếu bạn không suy nghĩ về tên có ý nghĩa và tên tái cấu trúc khi họ không còn mô tả chức năng nữa.

1

Tôi không biết rằng có một tổ chức tiêu chuẩn trong XCode, đặc biệt là kể từ khi tổ chức dự án bên trong IDE thường không dịch tập tin tổ chức trên đĩa.

Điều đó nói rằng, tôi thường làm một cái gì đó tương tự như Tùy chọn 1 của bạn, không có lý do nào tốt hơn so với cấu trúc thư mục trong Rails, đó là những gì tôi được sử dụng nhiều nhất khi tôi bắt đầu rối tung với iPhone.

4

Tùy chọn thứ hai có ý nghĩa hơn khi dự án của bạn phát triển. Ngoài ra, dự án mặc định có các tệp xib được chuyển thành "tài nguyên" nhưng một lần nữa khi dự án phát triển, việc chuyển các tệp liên quan thành một nhóm lôgic cho một số màn hình hoặc một phần chức năng khác có ý nghĩa hơn rất nhiều.

Một sự sắp xếp nhóm bằng cách ví dụ sẽ là:

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) 

App đại biểu có thể đi chơi trong Utilitites, hoặc có lẽ chỉ nổi trên tất cả những nhóm dưới lớp.

+0

Các tiện ích con giao diện người dùng chung sẽ đi đâu trong hệ thống của bạn? Nói một tiện ích hộp kiểm kế thừa từ UIView và được sử dụng trên nhiều màn hình? –

+0

Có lẽ trong Tiện ích, trong một nhóm phụ UIWidget. –

0

Tùy chọn 2 có ý nghĩa hơn đối với tôi. Suy nghĩ về nó, trong khi bạn đang mã hóa, bạn luôn chỉnh sửa xung quanh "chế độ xem" và bộ điều khiển của nó, tùy chọn 2 giúp bạn tìm các tệp phù hợp theo cách hiệu quả nhất.

0

Các Xcode MVC cấu trúc thư mục giữa các ý kiến ​​như sau.

  1. CoreData: Chứa các lớp DataModel và Entity.

  2. Extension: chứa một lớp (mặc định mở rộng lớp táo + phần mở rộng lớp dự án.)

  3. Helper: Chứa các lớp học của bên thứ ba/Frameworks (. Ví dụ SWRevealController) + lớp Bridging (Obj C lớp trong Swift ví dụ. dựa trên dự án)

  4. Mô hình: Tạo một lớp đơn (ví dụ: A.ppModel - NSArray, NSDictionary, String, vv ..) để lưu dữ liệu. Dịch vụ Web Phân tích cú pháp và lưu trữ dữ liệu cũng được thực hiện ở đây.

  5. dịch vụ: Chứa các quy trình Web Service

  6. View (ví dụ như nhập xác minh, HTTP request/response.): Chứa storyboard, LaunchScreen.XIB và Xem Lớp học. Thực hiện một tế bào thư mục sub - chứa UITableViewCell, UICollectionView thoại di động, vv

  7. Bộ điều khiển: chứa logic hoặc Mã liên quan đến UIElements (ví dụ UIButton của tài liệu tham khảo + nhấp hành động.)

Tham khảo:

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

Lưu ý: Tôi đã đề cập đến lớp AppModel và AppController (Chúng là các lớp học singleton như AppDelegate)

Các vấn đề liên quan