Firstly, my apologies for submitting a question which is perhaps not strictly on-topic but hopefully the list will permit me a little latitude.
Thinking specifically of iOS Swift application design architecture I would be very interested to hear how other members map traditional MVC patterns to the architecture of the standard Xcode templates?
Should controller functions be incorporated in the AppDelegate or is it better to keep the AppDelegate minimal and put them in a separate controller module?
Is there any sensible demarcation point regarding which controller functions are acceptable in a ViewController? Does it make better sense to include them in the ViewController most closely associated with their actions or are they better placed in a separate module? In particular, I am trying to avoid breaking the rule regarding never having the V communicate directly with the M.
I appreciate this is a rather general question with no single right answer. I am happy simply to be pointed towards any guidance documentation which members may be aware of. I have read some of the Apple documentation but have not yet found any definitive answer.
Thank you,
Roy
Well you are right this is not the right place for such questions, because this mailing list is about pure Swift topics.
···
----
Think about MVC as MVVM where M = M, V = V and C = VM. Don't get confused by the `Controller` suffix, especially there is no `ViewController` suffix, because it always is and should be view name + controller suffix. That said, a view(controller) is a view and not a ViewModel. For navigation one could extend MVVM with a C for Coordinator (MVVM-C). I just said that you habe to think of MVC as MVVM. If you now apply the extended MVVM-C version backwards you'll get MVC-C, latter naming is confusing right!? ^^
Usually AppDelegate is your main object in your project, except if you need a custom subclass of UIApplication. MVVM-C is a good bullet proof arch. If you try to rethink everything that way you'll quickly notice how you can/should link your objects in such a project. Furthermore you should seperate your business logic completely from everything else, so that is kinda modular. This will help you testing your app and logic better and mantain a good app arch.
Hopefully I could help you a little.
--
Adrian Zubarev
Sent with Airmail
Am 23. Juni 2017 um 11:41:51, Roy Henderson via swift-users (swift-users@swift.org(mailto:swift-users@swift.org)) schrieb:
Firstly, my apologies for submitting a question which is perhaps not strictly on-topic but hopefully the list will permit me a little latitude.
Thinking specifically of iOS Swift application design architecture I would be very interested to hear how other members map traditional MVC patterns to the architecture of the standard Xcode templates?
Should controller functions be incorporated in the AppDelegate or is it better to keep the AppDelegate minimal and put them in a separate controller module?
Is there any sensible demarcation point regarding which controller functions are acceptable in a ViewController? Does it make better sense to include them in the ViewController most closely associated with their actions or are they better placed in a separate module? In particular, I am trying to avoid breaking the rule regarding never having the V communicate directly with the M.
I appreciate this is a rather general question with no single right answer. I am happy simply to be pointed towards any guidance documentation which members may be aware of. I have read some of the Apple documentation but have not yet found any definitive answer.
Thank you,
Roy
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
Should controller functions be incorporated in the AppDelegate or is it better to keep the AppDelegate minimal and put them in a separate controller module?
You start breaking up any controller if it is getting too big. You can use extensions, you can factor out code into structures or classes or you can add additional controllers. If you decide to introduce new controllers, make sure those do only communicate with the original controller or the model.
Also, only one controller should use any one model; other controllers talk to the model's controller.
In short, models and views should be leafs in the graph, while controllers provide the structure.
Is there any sensible demarcation point regarding which controller functions are acceptable in a ViewController? Does it make better sense to include them in the ViewController most closely associated with their actions or are they better placed in a separate module?
Well, deciding how to best organise your code is what software development is all about. There's no receipt you can follow to the letter. Just best practices and tips. So without knowing more details, it is hard to answer this question.
In particular, I am trying to avoid breaking the rule regarding never having the V communicate directly with the M.
I'm not sure how that is related? Breaking up the controller in multiple parts doesn't change the connections to the view or the model.
If you want to continue this discussion, maybe the cocoa-dev list would be acceptable.
Andreas
···
Am 23.06.2017 um 11:41 schrieb Roy Henderson via swift-users <swift-users@swift.org>: