search

wtsnz / Coordinator-Example

An example of the Coordinator pattern
169 stars 31 forks source link

Coordinator - some questions only #3

Open jontelang opened 6 years ago

jontelang commented 6 years ago

I am basically just asking here as the blog didn't have a commenting area.

Looking around at Coordinator patterns, I struggle a bit with knowing where to place the actual business logic. In your example, at least I can see that you put it in the Coordinator itself. However this makes me wonder about a few things.

  1. Extensions makes it nice in Swift to separate the logic, but what about Objective C, it feels like using categories would be the equivalent?

  2. If a view controller always needs to be setup with data X from a service. That means the (as in your blog post) logic for errors and actual api calls need to be duplicated in multiple coordinator classes?

  3. Just an observation, there will be a lot of business logic in the coordinator the more steps it have. Which is maybe annoying, I'm considering that maybe these steps would be able to be moved into a "business logic" class (maybe ViewModel type of thing). Wondering if you came across this in the final application. This also ties into the 2nd questions, with duplication.

  4. If you have e.g. a menu and one "flow" consists of only one view controller, would it still have a specific flow class for that one? (not exactly sure about this questions but I'll add it anyway)

WilliamWishart commented 6 years ago

Business logic should not be in the View Controllers or the Coordinators, it should be further down in either a business service layer or in the business domain objects.

You may see simple examples with business rules closer to the UI, but that’s more likely a symptom of the example trying to keep it simple by avoiding all the infrastructure typical of a larger app.

jontelang commented 6 years ago

I'm implementing a test project just to get a feel for how it works. And I'm at a page where I'd like to skip a VC in the flow similar to in the example app you had in the blog.

The example goes like

didEnterEmail:email
   if email contains "example.com"
       showCompleted
   else
       showEmailIsBlocked

But the decision to have the email blocked would be a business logic decision, thus not supposed to be in this coordinator class. So in this case what would be an appropriate way to decide on the flow? I'm leaning towards some form of "Email wrapper" model object that contains a method "isValidForRegisrationFlow", or similar but I'm not sure if it is a good idea.

Or possibly a model object specifically for the flow, that in turn contains this logic (including same logic for other steps, such as e.g. name/pwd validation/etc).

Sorry for the unsolicited questions