Tại sao tài liệu của Apple nhận được ManagedObjectContext từ UIApplicationDelegate là xấu?

Question

Chỉ cần tò mò tại sao ManagedObjectContexts phải được chuyển đến UIViewControllers khi chúng được tạo ra, thay vì chỉ lấy chúng từ một UIApplicationDelegate?

Các tài liệu nói rằng điều này làm cho ứng dụng của bạn cứng nhắc hơn, nhưng tôi không thấy các sắc thái khi sử dụng mẫu nào.

Cảm ơn!

Answer 1

Hãy tưởng tượng rằng tôi yêu cầu bạn thực hiện một số tác vụ, như vẽ một căn phòng. Nếu tôi chỉ nói với bạn "hãy đi sơn một phòng", bạn sẽ cần hỏi tôi rất nhiều câu hỏi, như:

• Phòng nào?
• Sơn ở đâu?
• Bàn chải ở đâu?
• Tôi có nên sử dụng khăn trải giường không?

Tóm lại, bạn sẽ không thể hoàn thành tác vụ mà không có sự trợ giúp của tôi. Nếu bạn phải phụ thuộc vào tôi mỗi lần, bạn sẽ không phải là một họa sĩ rất linh hoạt. Một cách để đối phó với vấn đề đó là để tôi cung cấp cho bạn tất cả những thứ bạn cần ngay từ đầu. Thay vì "đi sơn một căn phòng," tôi sẽ nói "xin vui lòng sơn số phòng 348 bằng cách sử dụng xô sơn này và bàn chải này, và không bận tâm với một dropcloth." Bây giờ, bạn đã có mọi thứ bạn cần và bạn có thể có quyền làm việc mà không cần thêm sự trợ giúp nào từ tôi. Bạn là một công nhân linh hoạt hơn nhiều bởi vì bạn không còn phụ thuộc vào tôi nữa.

Điều tương tự cũng áp dụng để xem bộ điều khiển (và đối tượng nói chung); nó tốt hơn để cung cấp cho họ tất cả mọi thứ họ cần hơn để có họ phụ thuộc vào một đối tượng cụ thể như các ứng cử viên đại biểu. Đó là sự thật không chỉ cho bối cảnh đối tượng được quản lý, mà còn cho bất kỳ thông tin nào họ cần để thực hiện công việc của mình.

Answer 2

Điều này chủ yếu là vì bạn muốn sử dụng dependency injection với UIViewControllers thay vì chỉ lấy tất cả mọi thứ từ UIApplication, điều này giúp đại biểu của bạn sạch sẽ thay vì đầy đủ các tham chiếu.

Đây cũng là để giữ với mô hình MVC:

1. Mẫu

2. View Controller (Chỉ dành cho logic xem)

3. Controller (Đối phối hợp giữa quan điểm và mô hình)

Answer 3

Tôi có xu hướng không đồng ý với điều này pa ttern.

Trước hết, tôi cố gắng xử lý Dữ liệu cốt lõi dưới dạng chi tiết triển khai và như bất kỳ chi tiết triển khai nào cần được ẩn đằng sau mặt tiền tốt. Mặt tiền là các giao diện mà tôi trưng ra cho các đối tượng mô hình của mình. Ví dụ nếu tôi có hai đối tượng mô hình; Cource và Student, bất kỳ tòa án nào cũng có thể có một số học sinh. Tôi không muốn để cho bộ điều khiển thực hiện nhiệm vụ thiết lập các biến vị ngữ và các bộ mô tả sắp xếp, và nhảy qua tất cả các vòng dữ liệu cốt lõi chỉ để có được một danh sách các sinh viên cho một lớp cụ thể. Có một cách hoàn toàn hợp lệ để hiển thị điều này trong mô hình:

@interface Cource (StudentAccess) 
-(NSArray*)studentsStortedByName; 
@end 

Sau đó, triển khai công cụ xấu xí một lần và cho tất cả trong lớp Mô hình. Ẩn tất cả các chi tiết phức tạp của Dữ liệu cốt lõi và không cần phải vượt qua các bối cảnh đối tượng được quản lý. Nhưng làm thế nào tôi có thể tìm thấy các nguồn, nó phải bắt đầu ở đâu đó đúng không? Có, nó không nhưng bạn không cần phải tiếp xúc với bộ điều khiển. Việc thêm các phương pháp như vậy cũng hoàn toàn hợp lý:

@interface Cource (CourceAccess) 
+(Cource*)caurceByID:(NSString*)courceID; 
+(NSArray*)allCources; 
+(NSArray*)courcesHeldByTeacher:(Teacher*)teacher; 
@end 

Điều này cũng giúp giảm thiểu sự phụ thuộc giữa các bộ điều khiển. Và giảm bớt sự phụ thuộc giữa mô hình và bộ điều khiển. Giả sử tôi có một CourceViewController và StudenViewController là tôi không giấu nổi những chi tiết cốt lõi dữ liệu đằng sau một mặt tiền và muốn vượt qua xung quanh bối cảnh đối tượng quản lý là tốt, sau đó tôi sẽ kết thúc với một initializer định như thế này:

-(id)initWithManagedObjectContext:(NSManagedObjectContext*)moc 
          student:(Student*)student; 

trong khi đó với tốt một mặt tiền tốt tôi kết thúc với điều này:

-(id)initWithStudent:(Student*)student; 

Giảm thiểu sự phụ thuộc đằng sau mặt tiền, ủng hộ của dependency injection cũng làm cho nó dễ dàng hơn để thay đổi việc triển khai nội bộ. Việc truyền xung quanh bối cảnh đối tượng được quản lý sẽ khuyến khích mỗi bộ điều khiển thực hiện logic riêng của chúng cho các công cụ cơ bản. Lấy ví dụ studentsSortedByName. Lúc đầu, nó có thể được sắp xếp theo họ/tên, nếu sau này thay đổi để sắp xếp tên/cuối cùng bạn sẽ phải đi đến mỗi và mọi bộ điều khiển đã sắp xếp sinh viên và thực hiện thay đổi.Trường hợp một phương pháp mặt tiền tốt yêu cầu bạn thay đổi trong một phương pháp, và tất cả các bộ điều khiển tự động nhận được bản cập nhật miễn phí.

Answer 4

Apple Documents cố gắng thúc đẩy các mẫu thiết kế được áp dụng rộng rãi và bền vững nhất. Chèn phụ thuộc được ưu tiên vì nó cho phép thiết kế linh hoạt, có thể mở rộng, tái sử dụng và duy trì được.

Khi các ứng dụng phát triển phức tạp, sử dụng bãi đỗ xe gần như đơn lẻ, bối cảnh trong ủy nhiệm ứng dụng bị hỏng. Trong các ứng dụng phức tạp hơn, bạn có thể có nhiều bối cảnh gắn với nhiều cửa hàng. Bạn có thể muốn cùng một bộ điều khiển xem/cặp để hiển thị dữ liệu từ ngữ cảnh khác nhau tại các thời điểm khác nhau hoặc bạn có thể kết thúc với nhiều bối cảnh trên các chủ đề/hoạt động khác nhau. Bạn không thể chồng tất cả các bối cảnh đó lên trong ứng dụng đại biểu.

Nếu bạn có một ứng dụng đơn giản với một bối cảnh duy nhất thì sử dụng bán đơn với đại biểu ứng dụng có thể hoạt động tốt. Tôi đã sử dụng nó trên một số ứng dụng nhỏ hơn trong quá khứ mà không có vấn đề ngay lập tức nhưng tôi đã nhấn vấn đề khả năng mở rộng trên một vài ứng dụng khi các ứng dụng phát triển thêm giờ.

Mẫu sử dụng nào phụ thuộc vào hạn chế giao hàng của bạn và bạn đoán tốt nhất về ứng dụng tiến hóa trong toàn bộ vòng đời của nó. Nếu ứng dụng của nó là một ứng dụng nhỏ, thì ứng dụng ủy nhiệm bán đơn sẽ hoạt động tốt. Nếu ứng dụng phức tạp hơn, có thể phát triển phức tạp hơn hoặc có thể sinh ra các ứng dụng liên quan khác sẽ sử dụng lại các thành phần hiện có, sau đó tiêm phụ thuộc là cách để đi.