从模型到其他ViewController的返回变量

发布于 2025-01-29 14:25:24 字数 418 浏览 2 评论 0原文

我正在做天气申请。我基本上创建了一个只能从API获取数据并根据需要返回数据的课程。我有Cityname，CurrentWeather等的变量。问题是有时无法提供全部API，因此我需要检查它们是否在返回之前零。我想到的是首先设置了这样的变量：

private var cityNamePrivate: String!

但是

var cityNamePublic: String {

if cityNamePrivate == nil {
    // 
}
else { return cityNamePrivate }

，如您所知，它非常糟糕，因为我有很多变量。有更好的逻辑吗？我是否应该退还它们，然后在我发送的任何地方检查吗？

原文

I am making a weather application. I basically created a class where I will only get data from API and return them as needed. I have variables like cityName, currentWeather etc.
Problem is sometimes API doesn't provide them all so I need to check if they are nil or not before return them. What comes to my mind is set variables like this first:

private var cityNamePrivate: String!

and then

var cityNamePublic: String {

if cityNamePrivate == nil {
    // 
}
else { return cityNamePrivate }

But as you can as imagine, its very bad because I have a lots of variables. Is there any better logic for this? Should I just return them and check later in wherever I send them?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

ι不睡觉的鱼゛ 2025-02-05 14:25:24

这里的问题是您将有许多变量可以处理。它不仅是将它们从API中返回，还可以在您的应用程序中以及某些处理代码中与它们打交道。

一种解决方案是具有具有许多属性的大类或结构。这将很好地工作，很容易实施，但需要大量重复的代码。此外，只要远程Web服务提供了一些新属性，就需要更改您的API和所有代码。

另一种方法是用动态容器替换大型僵化的类或结构，例如，一组项目[item]或将名称与项目相关联的字典[string：string：item] < /代码>。如果数据只是字符串，则很简单。如果是几种类型，则可能必须为元素实现一个小型系统。示例：

var x : [ String: String] = [:]
x["city"]="Strasbourg"
x["temperature"]="34°C"

struct Item {
    var name : String
    var value : String
}
var y : [ Item ] = [Item(name:"city",value:"Strasbourg"),
                    Item(name:"temperature", value:"34°C")]

这种方法的另一个优点是您忠于语义：API中没有可用的信息（例如“未知”）与默认值不同。即，如果天气API不返回温度，则不会在应用程序中显示0。因为0与“未知”不同。尽管在此问题上琴弦更强大，但缺少名称与空名称不同。

最后一句话表明，在您当前的方案中，要拥有一个大数据传输对象，您应该考虑将属性视为可选的，并将处理未知数据处理的责任转移到您的应用中。

The problem here is that you will have many variables to deal with. It's not just returning them from the API, it's also dealing with them in your app and perhaps in some processing code.

One solution is to have a big class or struct with many properties. This will work very well, is straightforward to implement but will require lots of repetitive code. Moreover, it will require to change your API and all your code, whenever some new properties are made available by the remote web service.

Another approach is to have replace the big inflexible class or struct, with a dynamic container, e.g. an array of items [ Item ] or a dictionary that associates names to items [ String : Item ]. If the data is just strings, it's straightforward. If it's several types, you may have to have to implement a small type system for the elements. Example:

var x : [ String: String] = [:]
x["city"]="Strasbourg"
x["temperature"]="34°C"

struct Item {
    var name : String
    var value : String
}
var y : [ Item ] = [Item(name:"city",value:"Strasbourg"),
                    Item(name:"temperature", value:"34°C")]

The other advantage of this approach is that you stay loyal to the semantics: an information that is not available in the API (e.g. "unknown") is not the same as a default value. I.e. if the weather API does not return a temperature, you will not display 0 in your app. because 0 is not the same as "unknown". While strings are more robust in this matter, the absence of a name is not the same as an empty name.

This last remark suggests that in your current scheme, of having a big data transfer object, you should consider to keep the properties as optional, and move the responsibility for the processing of unknown data to your app.

回复收藏 0 原文

~没有更多了~