Swift MVVM — Models = Tuples?

Working on one of my projects I ran into the common issue I have in Swift where I decide how I should represent the model. Everything used to be inside of class when I first began programming in Swift. I soon took a step back from this approach as I looked into the language and found that in most cases I should probably use a struct.

But lately I’ve really been thinking this issue over. Why is it that I default to structs when trying to practice the ways of MVVM and MVP? It seems like structs are the go-to structure for the model but should it be?

Using https://blogs.msdn.microsoft.com/msgulfcommunity/2013/03/13/understanding-the-basics-of-mvvm-design-pattern/ as a resource to define MVVM, you find that the Model is simply just the data and the View Model is the layer that handles how the Model is formatted before being displayed. Here’s a look at this process as written in C#.

Having said that, why use structs in Swift? It seems like this is more of a job for Tuples.

The question then becomes this: If tuples and structs are both value types, then why use the tuple over the struct? I’m choosing to use tuples over structs because structs invite the opportunity to cheat on the concept of MVVM. If the View Model is meant to manipulate the data before it’s displayed then you should make sure there’s absolutely no way the data can manipulate itself before the View Model does. If someone is new to the project and they’re not entirely sure what’s going on, then they may begin adding behavior into the struct. They may add a way for the data to represent itself in a different way. This can be an issue.

Another reason for tuples over structs in this situation is that the Book tuple can be used wherever you define (String,String,String,String) and vice-versa. With structs, if you create something like:

You’ll never be able to use a Book wherever you use a Movie. Knowing this means that your View Models for each controller will have to be two separate things. You could of course use generics but you’ll run into problems the moment you try to display anything specific:

Type parameter T has no idea what properties it should have so how would it know to display a title when it’s not sure whether or not it even has one?

Compare that to the use of tuples:

So with tuples you get a certain level of abstraction you don’t get with structs. You’re able to reuse many things a struct wouldn’t let you reuse and you get to carry on with MVVM without much of a problem.

Bonus:

You may be looking at the typealias and wondering how good of an idea that is. What if you placed the title in the wrong spot? Well, that’s where tuples have you covered. With tuples, it doesn’t matter the order you place the values inside of it. All that matters is that you match intention with the type parameter name. The typealias MediaItem displays “title” in the first section of the tuple but you could easily move “title” to the 4th if you actually placed the title in that spot.

Tuples are very smart and intuitive, and knowing this, I believe we should be using them more often than we do.

Show your support

Clapping shows how much you appreciated Markim Shaw’s story.