Repository files navigation

Library is an iOS application built to highlightMVP (Model View Presenter) andClean Architecture concepts

• Xcode 10.2.1
• Swift 5

• View - delegates user interaction events to thePresenter and displays data passed by thePresenter
  • AllUIViewController,UIView,UITableViewCell subclasses belong to theView layer
  • Usually the view is passive / dumb - it shouldn't contain any complex logic and that's why most of the times we don't need write Unit Tests for it
• Presenter - contains the presentation logic and tells theView what to present
  • Usually we have onePresenter per scene (view controller)
  • It doesn't reference the concrete type of theView, but rather it references theView protocol that is implemented usually by aUIViewController subclass
  • It should be a plainSwift class and not reference anyiOS framework classes - this makes it easier to reuse it maybe in amacOS application
  • It should be covered by Unit Tests
• Configurator - injects the dependency object graph into the scene (view controller)
  • You could very easily use a DI (dependency injection) library. Unfortunately DI libraries are not quite mature yet oniOS /Swift
  • Usually it contains very simple logic and we don't need to write Unit Tests for it
• Router - contains navigation / flow logic from one scene (view controller) to another
  • In some communities / blog posts it might be referred to as aFlowController
  • Writing tests for it is quite difficult because it contains many references toiOS framework classes so usually we try to keep it really simple and we don't write Unit Tests for it
  • It is usually referenced only by thePresenter but due to thefunc prepare(for segue: UIStoryboardSegue, sender: Any?) method we some times need to reference it in the view controller as well

• UseCase / Interactor - contains the application / business logic for a specific use case in your application
  • It is referenced by thePresenter. ThePresenter can reference multipleUseCases since it's common to have multiple use cases on the same screen
  • It manipulatesEntities and communicates withGateways to retrieve / persist the entities
  • TheGateway protocols should be defined in theApplication Logic layers and implemented by theGateways & Framework Logic
  • The separation described above ensures that theApplication Logic depends on abstractions and not on actual frameworks / implementations
  • It should be covered by Unit Tests
• Entity - plainSwift classes / structs
  • Models objects used by your application such asOrder,Product,Shopping Cart, etc

• Gateway - contains actual implementation of the protocols defined in theApplication Logic layer
  • We can implement for instance aLocalPersistenceGateway protocol usingCoreData orRealm
  • We can implement for instance anApiGateway protocol usingURLSession orAlamofire
  • We can implement for instance aUserSettings protocol usingUserDefaults
  • It should be covered by Unit Tests
• Persistence / API Entities - contains framework specific representations
  • For instance we could have aCoreDataOrder that is aNSManagedObject subclass
  • TheCoreDataOrder would not be passed to theApplication Logic layer but rather theGateways & Framework Logic layer would have to "transform" it to anOrder entity defined in theApplication Logic layer
• Framework specific APIs - contains implementations ofiOS specific APIs such as sensors / bluetooth / camera

• The demo applications tries to expose a fairly complex set of features that justifies the usage of the concepts presented above
• The followingUnit Tests have been written:
  • BooksPresenterTest - highlights how you can test the presentation logic
  • DeleteBookUseCaseTest - highlights how you can test the application / business logic and also how to test async code that uses completion handlers andNotificationCenter
  • CacheBooksGatewayTest - highlights how you can test a cache policy
  • CoreDataBooksGatewayTest - highlights how you can test aCoreData gateway
  • ApiClientTest - highlights how you can test the API / Networking layer of your application by substituting theURLSession stack
• Code comments can be found in several classes highlighting different design decisions or referencing followup resources
• The project structure tries to mimic theScreaming Architecture concept that can be found in the references section
• High level UML diagram:

Giving that a large majority of mobile apps are a thin client on top of a set of APIs and that most of them contain little business logic (since most of the business logic is found in the APIs) some of theClean Architecture concepts can be debatable in the mobile world. Below you can find some:

• Creating a representation for each layer (API, CoreData) might seem like over-engineering. If your application relies heavily on an API that is under your control then it might make sense to model both the entity and the API representation using the same class. You shouldn't however allow the persistence representation (theNSManagedObject subclass for instance) leak in the other layers (seeParse example that got discontinued)
• If you find that in most cases yourUse Cases / Interactors simply delegate the actions to theGateway then maybe you don't need theUse Cases / Interactors in the first place and you can use theGateway directly in thePresenter
• If you want to enforce the layer separation even more you can consider moving all the layers in their own projects / modules
• Some might consider that creatingdisplay(xyz: String) methods on aCellView protocol is over-engineering and that passing a planeCellViewModel object to theCellView and have the view configure itself with the view model is more straightforward. If you want top keep the view as passive / dumb as possible then you should probably create the methods, but then again simply reading some strings from a view model and setting some labels is not really complex logic

The list above is definitely not complete, and if you identify other debatable decisions please create an issue and we can discuss about it and include it in the list above.

For the items listed above (and also for other items of your own) it is important that you useyour own judgement and make aninformed decision.

Keep in mind that you don't have to make all the design decisions up front and that you can refactor them in as you go.

Discuss about all the design decision with your team members and make sure you are all in agreement.

• iOS Architecture Patterns
• Architecture Wars - A New Hope
• VIPER to be or not to be?
• Effective Android Architecture - our note here is that you should be careful about coupling you application to Rx* or any other framework for that matter. Please readMake the Magic go away, by Uncle Bob and think twice before letting a framework take over your application.
• Improve your iOS Architecture with FlowControllers
• GUI Architectures, by Martin Fowler

• The Clean Architecture, by Uncle Bob
• Architecture: The Lost Years, by Uncle Bob
• Clean Architecture, By Uncle Bob
• Uncle Bob's clean architecture - An entity/model class for each layer?

• xUnit Test Patterns: Refactoring Test Code
• The Art of Unit Testing: with examples in C#

Please feel free to open an issue for any questions or suggestions you have!