Nơi đặt "Ngăn xếp dữ liệu cốt lõi" trong ứng dụng Cocoa/Cocoa Touch

Question

Trong Mẫu dữ liệu lõi iPhone, Apple đặt Ngăn xếp dữ liệu cốt lõi trong App Delegate.

Tuy nhiên, độ nghiêng ban đầu của tôi là di chuyển mã này vào lớp riêng của mình mà trách nhiệm của họ là xử lý việc quản lý Ngăn xếp dữ liệu cốt lõi.

Bạn thường đóng gói chức năng này trong lớp học của riêng mình hay bạn để nó trong App Delegate?

Answer 1

Tóm tắt: Không cần để tạo ra một singleton để quản lý dữ liệu cốt lõi chồng; thực sự làm như vậy có khả năng phản tác dụng.

Ngăn xếp dữ liệu cốt lõi sẽ do đại biểu ứng dụng tạo ra. Quan trọng hơn, tuy nhiên, như tất cả các ví dụ hiển thị, ngăn xếp (chủ yếu là bối cảnh đối tượng được quản lý) là không phải được truy xuất trực tiếp từ ngăn xếp (*). Thay vào đó, ngữ cảnh được chuyển đến bộ điều khiển xem đầu tiên, và từ chúng trên một ngữ cảnh hoặc một đối tượng được quản lý được truyền từ một bộ điều khiển xem sang bộ điều khiển xem tiếp theo (như được mô tả trong Accessing the Core Data Stack). Điều này theo mô hình cơ bản cho iPhone tất cả các ứng dụng: bạn chuyển dữ liệu hoặc một bộ điều khiển mô hình từ một bộ điều khiển xem sang bộ điều khiển xem tiếp theo.

Vai trò tiêu biểu của singleton như được mô tả ở đây là bộ điều khiển mô hình. Với Core Data, bối cảnh đối tượng được quản lý đã là một bộ điều khiển mô hình. Nó cũng cung cấp cho bạn khả năng truy cập các phần khác của ngăn xếp nếu cần. Hơn nữa, trong một số trường hợp (như được mô tả trong tài liệu), bạn có thể muốn sử dụng một ngữ cảnh khác để thực hiện một bộ hành động riêng biệt. Đơn vị tiền tệ thích hợp cho một bộ điều khiển khung nhìn do đó thường là một bối cảnh đối tượng được quản lý, nếu không một đối tượng được quản lý. Sử dụng và truyền một đối tượng đơn lẻ quản lý một ngăn xếp (và từ đó bạn lấy một ngữ cảnh) thường giới thiệu tốt nhất một mức độ không cần thiết của sự hướng dẫn, và lúc tồi tệ nhất giới thiệu độ cứng ứng dụng không cần thiết.

(*) Không dụ lấy bối cảnh sử dụng:

[[UIApplication delegate] managedObjectContext]; 

Answer 2

Tôi có một lớp singleton mà tôi cho phép quản lý dữ liệu cốt lõi của mình và tôi không để nó trên ủy nhiệm ứng dụng. Tôi không thích lộn xộn lớp đại biểu ứng dụng với các phương pháp tôi có thể cần cho conviniece như lấy đối tượng nhất định vv

Answer 3

tôi rời khỏi logic dữ liệu cốt lõi trong các đại biểu ứng dụng vì những lý do sau đây:

1) Tôi không thấy bất kỳ lợi thế thực sự nào trong việc di chuyển mã này trong các lớp khác: khái niệm về ủy nhiệm hoàn toàn được thực hiện bởi logic dữ liệu cốt lõi do ứng dụng ủy nhiệm xử lý vì mô hình dữ liệu cốt lõi thực sự là một phần cơ bản của ứng dụng của bạn;

2) Trong tất cả các mã mẫu tôi đã thấy, bao gồm các mẫu của Apple, dữ liệu cốt lõi được xử lý bởi ứng dụng ủy nhiệm;

3) Ngay cả trong sách Cốt lõi dữ liệu, thực tế phổ biến là yêu cầu ủy nhiệm ứng dụng xử lý mã liên quan đến dữ liệu cốt lõi;

4) Cá nhân tôi không nghĩ rằng khả năng đọc hay bất cứ điều gì khác thực sự được cải thiện bằng cách có lớp học đặc biệt cho dữ liệu cốt lõi, nhưng đây là vấn đề cá nhân và tôi sẽ không tranh luận ở đây phương pháp nào là tốt nhất. Đối với tôi, tính đơn giản trong khi giữ lại chức năng là quan trọng.

Answer 4

Câu hỏi tôi muốn tự hỏi, trong trường hợp của bạn, là "ai thực hiện ngăn xếp Dữ liệu cốt lõi" thuộc về "?" Các dữ liệu chính nó thực sự là tỉnh của ứng dụng, phải không? (Dữ liệu lõi CF trên máy Mac, nơi bạn có thể có một ứng dụng có khả năng làm việc với nhiều tài liệu cùng một lúc, do đó, ngăn xếp Dữ liệu cốt lõi thuộc về mỗi tài liệu.)

Trong mọi ứng dụng Cocoa/Cocoa Touch, App Delegate thường là phương tiện ưa thích của việc tùy chỉnh hành vi của ứng dụng, vì vậy đây là nơi tự nhiên cho ngăn xếp Dữ liệu cốt lõi.

Bây giờ, vấn đề tôi nghi ngờ bạn đang gặp phải là nó cảm thấy sai lầm khi liên tục viết những thứ như:

NSManagedObjectContext *context = [(MyAppDelegate *)[[UIApplication sharedApplication] delegate] managedObjectContext]; 

Những gì tôi thường làm trong những trường hợp này là viết chức năng (không phải phương pháp) như thế này:

NSManagedObjectContext *UIAppManagedObjectContext() { 
    return [*(MyAppDelegate *)[[UIApplication sharedApplication] delegate] managedObjectContext]; 
} 

Tôi viết chức năng tương tự cho NSPersistentStoreCoordinator và NSManagedObjectModel. Tôi đặt tất cả các tệp này trong các tệp .h/.m của App Delegate, vì đây cũng là các đối tượng cấp ứng dụng.

Answer 5

Tôi ủng hộ việc ủy ​​quyền ứng dụng biết nơi mô hình bắt đầu và có mô hình biết ngữ cảnh đối tượng được quản lý ở đâu. Dữ liệu cốt lõi - "ness" của mô hình có vẻ giống như một chi tiết thực hiện của mô hình với tôi, các lớp điều khiển (như ủy nhiệm ứng dụng) chỉ nên hỏi "cung cấp cho tôi thông tin này về mô hình" và mô hình nên biết cách trả lời câu hỏi đó. Vì vậy, có một đối tượng dữ liệu lõi có sẵn thông qua một đối tượng điều khiển có vẻ như một trừu tượng bị rò rỉ.

Answer 6

Tôi sẽ chỉ liệt kê điều này trong câu trả lời mới.(Tôi đã loại bỏ lớp FJSCoreDataStack trước đó của tôi để ủng hộ điều này)

Cách xử lý mới của tôi là sử dụng một danh mục trên NSManagedObjectContext. Ive đã thêm các phương thức lớp sau:

+ (NSManagedObjectContext *)defaultManagedObjectContext; 
+ (NSManagedObjectContext *)scratchpadManagedObjectContext; 
+ (NSManagedObjectModel *)managedObjectModel; 
+ (NSPersistentStoreCoordinator *)persistentStoreCoordinator; 
+ (NSString *)applicationDocumentsDirectory; 

Điều này giúp mọi thứ không được ủy quyền ứng dụng và cho phép truy cập đơn nên tôi chọn sử dụng. Tuy nhiên, tôi vẫn sử dụng tiêm phụ thuộc từ App Delegate (như mmalc đã nói, nó giới thiệu tính không linh hoạt vào mã của tôi). Tôi chỉ đơn giản là di chuyển tất cả các "Core Data Stack" mã vào NSManagedObjectCOntext Category.

Tôi thích chuyển tham chiếu xung quanh, đặc biệt là vì tôi có phương pháp "ngữ cảnh bàn phím" đẹp. Điều này giữ cho bộ điều khiển View của tôi linh hoạt vì tôi chưa cam kết chúng với "defaultManagedObjectContext".

Cũng liên quan đến cuộc trò chuyện trong thế giới iPhone (và có thể có một ảnh hưởng trên kiến ​​trúc của bạn): NSFetchedResultsController and constructing NSFetchRequests