Quote:
Originally Posted by exorcyze
Well it's nothing terribly magical, and I'll assume that anyone reading this can parse out the header vs module code and that stubs of course have code in them, but maybe this will help the idea:
>snip
|
Got it!
It seems as there 4 stages of evolution of the Model.
1) Define data in the View/VC that uses it (or anywhere else that makes sense) -- works for examples and simple apps.
2) Load up the appDelegate with data definitions and the methods to manipulate them-- where I am.
3) refactor the Model definition/methods out to separate class(es)-- where exorcyze is.
4) design speciality classes to:
---- define the data (the model)
---- define the methods (and external interfaces) that act on the data (the Model Controller)
where eddietr is.
What is interesting is that (in 3 and 4) the appDelegate becomes the point-guard (distributing the ball) without being overloaded with unnecessary complexity (neither are the VCs or the Views).
i think I like this... It makes sense... I can implement as much (or as little) as I want to support a specific app, without feeling like I am going down a bad-practices blind alley.
As with all things, it is better to understand both ends of the spectrum when deciding to implement a technique.
exorcyze-- thanks for sharing your work... it really helps to show the way!
eddietr-- look forward to your tutorial/solution... I may not need to implement it for every app, but (hopefully) I can code even my most basic apps in such a way that they can easily be extend to a Model/Model Controller implementation.
Realistically. if the eddietr solution is not too expensive, I will implement it in every app for reasons of consistency, standardization and ease-of maintenance.
Thanks, guys!
Dick
