{"action":"created","issue":{"url":"https://api.github.com/repos/mutualmobile/VIPER-TODO/issues/4","repository_url":"https://api.github.com/repos/mutualmobile/VIPER-TODO","labels_url":"https://api.github.com/repos/mutualmobile/VIPER-TODO/issues/4/labels{/name}","comments_url":"https://api.github.com/repos/mutualmobile/VIPER-TODO/issues/4/comments","events_url":"https://api.github.com/repos/mutualmobile/VIPER-TODO/issues/4/events","html_url":"https://github.com/mutualmobile/VIPER-TODO/issues/4","id":51048474,"number":4,"title":"VIPER Issues","user":{"login":"scottrhoyt","id":4259250,"avatar_url":"https://avatars.githubusercontent.com/u/4259250?v=3","gravatar_id":"","url":"https://api.github.com/users/scottrhoyt","html_url":"https://github.com/scottrhoyt","followers_url":"https://api.github.com/users/scottrhoyt/followers","following_url":"https://api.github.com/users/scottrhoyt/following{/other_user}","gists_url":"https://api.github.com/users/scottrhoyt/gists{/gist_id}","starred_url":"https://api.github.com/users/scottrhoyt/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/scottrhoyt/subscriptions","organizations_url":"https://api.github.com/users/scottrhoyt/orgs","repos_url":"https://api.github.com/users/scottrhoyt/repos","events_url":"https://api.github.com/users/scottrhoyt/events{/privacy}","received_events_url":"https://api.github.com/users/scottrhoyt/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":37,"created_at":"2014-12-05T00:27:36Z","updated_at":"2016-03-10T16:24:42Z","closed_at":null,"body":"Sorry to repost here, but figured this would be better than the ObjCIO Github.\r\n\r\nHere's a few of things I am having a hard time figuring out using VIPER architecture:\r\n\r\nIf I have an entity that is just a data structure, and I have a presenter which is responsible for formatting data, why would I not want to pass the entity from interactor to presenter? I find myself unnecessarily creating two separate data structures (one on the interactor/entity side and one on the presenter side) which the interactor does a 1 to 1 mapping on. Is this correct?  Also, if you need to modify an entity based off of user interactions, how do you do this without violating layer boundaries and passing some reference to the entity to the presenter and/or view?  The only other option seems to be an ugly remapping in the interactor.\r\n\r\nHow does data get passed from one module to the next? Let's say I have a module that lists categories and a module that lists items in a category. When a user selects a category, that selections needs to be passed from the category module to the item module so that the item module interactor knows which category to retrieve. Data should be owned by the interactors, yet the transition between modules happens at the presenter/wireframe level. It seems I am stuck passing data from one interactor to another through their respective presenters/wireframes which results in a lot of unnecessary code and seems to violate the single responsibility of the presenter only presenting data to a view and a wireframe just transitioning between views.  There is also the layer boundary issue again because if you pass enough information for the second interactor to interact with the entity, then you are basically passing the entity... that or you have to do another ugly remapping the in second interactor. Should the interactors in different modules know about each other or communicate via a protocol? What's the best way to pass data between modules?\r\n\r\nAnd what is the proper role of wireframes?  Shouldn't they instantiate the entire stack (presenter, interactor, etc.) for their module and wire them up?  Seems like this is mostly happening in the AppDependencies class which feels like it will get out of hand quickly.  If wireframes own and configure the entire stack, then it feels like this might help a bit in passing information from one interactor to another, but would still violate boundaries or require interactors to communicate."},"comment":{"url":"https://api.github.com/repos/mutualmobile/VIPER-TODO/issues/comments/194934231","html_url":"https://github.com/mutualmobile/VIPER-TODO/issues/4#issuecomment-194934231","issue_url":"https://api.github.com/repos/mutualmobile/VIPER-TODO/issues/4","id":194934231,"user":{"login":"fatuhoku","id":430233,"avatar_url":"https://avatars.githubusercontent.com/u/430233?v=3","gravatar_id":"","url":"https://api.github.com/users/fatuhoku","html_url":"https://github.com/fatuhoku","followers_url":"https://api.github.com/users/fatuhoku/followers","following_url":"https://api.github.com/users/fatuhoku/following{/other_user}","gists_url":"https://api.github.com/users/fatuhoku/gists{/gist_id}","starred_url":"https://api.github.com/users/fatuhoku/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/fatuhoku/subscriptions","organizations_url":"https://api.github.com/users/fatuhoku/orgs","repos_url":"https://api.github.com/users/fatuhoku/repos","events_url":"https://api.github.com/users/fatuhoku/events{/privacy}","received_events_url":"https://api.github.com/users/fatuhoku/received_events","type":"User","site_admin":false},"created_at":"2016-03-10T16:24:42Z","updated_at":"2016-03-10T16:24:42Z","body":"Hmmm. I think 'VIPER' as a concept is given more credit than it deserves. As we've discussed there, there's components whose responsibility are half-baked.\r\n\r\nI recently saw [this video](https://www.youtube.com/watch?v=o_TH-Y78tt4) and understood where VIPER came from.\r\n\r\nThen I found this: http://clean-swift.com/clean-swift-ios-architecture/. A certain Raymond Law wrote up how he thought of applying Clean to Swift. I like that it really gets you right back to the first principles again... to realise that whatever you're doing with your code, whatever you want to call it, whether it be VIPER, MVVM or MVC.\r\n\r\nYou really want to be pushing your implementation details to the edges. Protect the details of your business logic."}}