swift编写的项目源代码_通过在Swift中命名模型来编写简洁的代码

swift编写的项目源代码

I have been using namespaced models a lot recently in my projects and at work, so I decided to share the idea in this article.

我最近在我的项目和工作中一直使用命名空间模型，因此我决定在本文中分享这个想法。

One of the challenges when trying to write clean and modular code is deciding how to declare our models. Models may be requests or responses from an API or simple locally created view models that we can pass to a view to configure it.

尝试编写简洁的模块化代码时的挑战之一就是确定如何声明我们的模型。 模型可以是来自API的请求或响应，也可以是我们可以传递给视图进行配置的简单本地创建的视图模型。

In this article, we will explore how you can use Swift’s caseless enums to easily namespace your models. But first, why would you even bother namespacing your models?

在本文中，我们将探讨如何使用Swift的无大小写枚举轻松地为模型命名。 但是首先，为什么还要打扰模型的命名呢？

Namespacing models comes with two main benefits:

名称间隔模型具有两个主要优点：

1. Cleanliness. To write clean and modular code, we want to make our models distinctly belong to their module and be recognized almost instantly while looking at the code.
   清洁度。 为了编写简洁的模块化代码，我们希望使我们的模型明显属于它们的模块，并在查看代码时几乎立即被识别出来。
2. Avoiding mistakes further into development. Not confusing one model for another.
   避免错误进一步发展。 不要混淆一个模型与另一个模型。

Let’s say you have a screen that shows a list of cars.

假设您有一个显示汽车列表的屏幕。

You would want to have a car model available to your whole application/framework. However, the API response model will be specific to your cars list screen. Our cars list module will also need a view model that will be specific to the cars list screen. As they are specific to the cars list, both the response and view models could be neatly namespaced and distinctly belong to the cars list module since we use them only in that context.

您可能希望为整个应用程序/框架提供汽车模型。 但是，API响应模型将特定于您的汽车列表屏幕。 我们的汽车列表模块还将需要一个特定于汽车列表屏幕的视图模型。 由于它们专用于汽车列表，因此响应模型和视图模型都可以整齐地命名，并且明确属于汽车列表模块，因为我们仅在这种情况下使用它们。

Let’s see examples of the above using two architectural patterns you might be working with: MVVM and Clean Swift.

让我们使用可能使用的两种架构模式来查看上述示例：MVVM和Clean Swift。

MVVM示例 (MVVM Example)

You can see that alongside CarsListViewController, there is the CarsList enum with the LoadingCars nested enum that has Model and ViewModel structs.

您可以看到CarsListViewController旁边是CarsList枚举，其中的LoadingCars嵌套枚举具有Model和ViewModel结构。

So now your view model type can become CarsList.LoadingCars.ViewModel. If you compare that with a top-level struct named CarsListLoadedViewModel, you can notice a benefit of nesting your models and namespacing quickly.

因此，现在您的视图模型类型可以变成CarsList.LoadingCars.ViewModel 。 如果将其与名为CarsListLoadedViewModel的顶级结构进行比较，您会注意到快速嵌套模型和命名空间的好处。

Now to add new event models, you can add a new nested enum inside CarsList called SelectedCar that has its own Request and Model structs.

现在要添加新的事件模型，您可以在CarsList添加一个名为SelectedCar的新嵌套枚举，它具有自己的Request和Model结构。

In this example of namespacing, your view doesn’t know of all the cars that you parsed from the back end/database (Single Responsibility principle in SOLID). It only knows what it has to know — carsViewModel: CarsList.LoadingCars.ViewModel to configure the list and selectedCar: CarsList.SelectedCar.Model, which you can then use to pass to a different detail screen.

在此命名空间示例中，视图不知道您从后端/数据库解析的所有汽车(SOLID中的“单一职责”原理)。 它只知道它必须知道的内容carsViewModel: CarsList.LoadingCars.ViewModel用于配置列表和selectedCar: CarsList.SelectedCar.Model ， 然后您可以使用它来传递到其他详细信息屏幕。

干净的Swift示例 (Clean Swift Example)

Let’s also have a look at the same cars list example using Clean Swift architecture.

让我们来看看使用Clean Swift架构的相同汽车清单示例。

If you’re not familiar with Clean Swift, you can read more about it in the official handbook .

如果您不熟悉Clean Swift，可以 在官方手册中 阅读有关它的更多信息 。

As with the MVVM implementation, you can see that alongside CarsListViewController, there is the CarsList enum with the LoadingCars nested enum that has Response and ViewModel structs.

与MVVM实现一样，您可以看到CarsListViewController旁边是CarsList枚举，其中的LoadingCars嵌套枚举具有Response和ViewModel结构。

Now we can easily construct the response in CarsListInteractor and pass it to CarsListPresenter. Then, using that response, we create a viewModel in CarsListPresenter and pass it to CarsListViewController. The VIP (view-interactor-presenter) cycle LoadingCars is now complete.

现在，我们可以轻松地在CarsListInteractor构造响应并将其传递给CarsListPresenter 。 然后，使用该响应，我们在viewModel中创建一个CarsListPresenter并将其传递给CarsListViewController 。 VIP(视图交互演示者)循环LoadingCars现在已完成。

With a SelectedCar nested enum inside CarsList, we can create Request, Response, and ViewModel structs to pass around in the SelectedCar VIP cycle.

通过在CarsList使用SelectedCar嵌套枚举，我们可以创建Request ， Response和ViewModel结构以在SelectedCar VIP周期中传递。

结论 (Conclusion)

With namespaced models, it should be easier to maintain the distinct models that we pass around in our code. In my time using namespaced models, I also found that it’s quick to spot what the code does and easy to change a model in the future if requirements change.

使用命名空间模型，应该更容易维护我们在代码中传递的不同模型。 在使用命名空间模型的时候，我还发现可以快速发现代码的作用，并且如果需求发生变化，将来可以轻松更改模型。

Thanks for reading!

谢谢阅读！

翻译自: https://medium.com/better-programming/write-clean-code-with-namespacing-models-in-swift-fdaed5f167de

swift编写的项目源代码