2020,最新Model的设计-APP重构之路

不少的app使用MVC设计模式来将“用户交互”与“数据和逻辑”分开,而model其中一个重要做用就是持久化。下文中设计的Model可能不是一个完美的,扩展性强的model范例,但在我须要重构的app中,这样的设计可以知足个人须要。面试

关于Model

Model层包含了app的数据与逻辑,Model层中的类须要关心的是数据的表现,存储,以及操做。Model层是整个app生态中相对独立的一个部分,由于它不会直接与controller层或者是View层进行通信,而是在其余层须要请求它的信息的时候进行间接通信。数据库

Model有什么用?

想要写好一个model,首先要清晰Model的做用。设计模式

  • 属性存取:将文件中的一些特性和数据以属性的形式存储
  • 可变性:属性能够readwrite,因此可以被改变,并保存到本地
  • KVO:能够观察一个属性的值并在它改变的时候受到通知,并以此对UI或其余地方进行控制
  • 处理数据:根据业务逻辑处理网络获取数据与本地存储数据

如何定义Model类

咱们能够建立一系列的Model类,它们之间能够互相继承,同时每个Model类是与当前app中的实体对应。好比在我当前须要重构的app中,用户数据对应的是UserInformationModel,班级信息对应的是StudentClassModelapi

另外一方面,在Model类的实现过程当中,有许多问题须要解决,因此我下面会根据我当前正在重构的app的一些状况结合来解释。缓存

信息的存储格式处理

数据能够以各类不一样的格式储存,在我重构的app中,数据等信息是使用普通的数据结构来存放,好比使用数据或者是字典来保存Model的信息。在一开始创建Model的时候并无太大的问题,可是当需求不断增长,一个Model类的信息开始变得庞大起来的时候,问题就开始浮现了。好比下面我要输出用户的姓名、年龄、班级、班主任、年级等数据。网络

// never do this !!!
- (void)printInformation
{
    NSLog(@"name: %@", [user objectForKey:@"name"]);
    NSLog(@"age: %@"m [user objectForKey:@"age"]);
    NSLog(@"class: %@"m [user objectForKey:@"clazz"]);
    NSLog(@"teacher: %@"m [user objectForKey:@"teacher"]);
    NSLog(@"grade: %@"m [user objectForKey:@"grade"]);
}

这样取出数据彷佛没什么问题,可是当数据多起来的时候就会发现代码会十分混乱,并且不!美!观!,同时最主要的问题是,在从字典中取出数据的过程当中会把key打错,致使数据取出失败。数据结构

因此在设计Model过程当中,尽量将Model设计成一个类而不是一个结构,在类中可使用属性(Property)来存取信息,它可以提供给开发者基本的拼写检查,彻底杜绝打错key致使的数据获取失败的状况,同时方便其余开发者看到Model中存储的数据类型,也方便往后的扩展与维护。app

// YES! do this!
- (void)printInformation
{
    NSLog(@"name: %@", user.name);
    NSLog(@"age: %@", user.age);
    NSLog(@"class: %@", user.clazz);
    NSLog(@"teacher: %@", user.teacher);
    NSLog(@"grade: %@", user.grade);
}

网络数据处理

因为我重构的app大部分功能是基于网络的,因此网络数据在Model层的处理会是重点。由于网络数据是异步获取的,并且获取过程很容易失败。因此网络数据的获取比本地数据的获取难度要更大。另外一方面,不少app的网络请求框架中都提供了缓存功能,能够在下一次请求中从缓存中更快的获取数据,而不须要再次进行网络请求,这里又涉及到本地数据获取等问题,使得网络数据的处理显得尤为繁琐。框架

在一个同步的网络环境下,咱们能够把错误处理放到其余地方,能够简单的作缓存,甚至能够像处理本地数据同样来更新、删除、添加新的网络数据。但很不幸的是,网络是异步的,因此咱们须要处理这个重要问题。异步

首先我在上文提到的缓存、失败处理,这些应该是交给网络请求框架来进行处理,最后获得一个responseObject,再对responseObject进行model转换等操做。

好比我在当前的项目中,是利用了MJExtension来进行字典与模型之间的转换,而这个转换,我是放到了每一个单独的API中,好比对于库存的请求,我在InventoryAPI中进行对responseObject转换成InventoryModel的操做,而不是放到vc中进行,这样在vc中仅仅是进行网络请求,请求完成后返回的是我想要的model。

InventoryAPI.m

- (id)modelingFormJSONResponseObject:(id)JSONResponseObject
{
    NSUInteger count = ((NSArray *)JSONResponseObject).count;
    NSMutableArray *modelsArray = [NSMutableArray array];
    for(int i = 0; i < count; i ++)
    {
        InventoryModel *model = [InventoryModel mj_objectWithKeyValues:JSONResponseObject[i]];
        [modelsArray addObject:model];
    }
    return modelsArray;
}

InventoryViewController

- (void)requestInformation
{
    [api startWithBlockSuccess:^(__kindof YXYBaseRequest *request) {
        // request.responseObject 将会返回modelsArray
    } failure:^(__kindof YXYBaseRequest *request, NSError *error) {

    }];
}

本地数据处理

本地数据有多种方式存储,比较常见的作法是使用.plist文件存储很是简单的数据,例如设置,而会使用SQLite数据库来存储其余复杂的数据。另外一方面,能够试着使用Core Data来对存储数据model,虽然Core Data会带来更多问题,甚至会影响性能,但它的NSFetchResultsController、懒加载、数据处理工具等也是十分的好用,因此……看本身。

在本地数据处理中,最重要的是如何获取和修改数据。在我如今须要重构的项目中并无太多的本地内容,绝大部份的数据都是经过网络获取,因此我并无准备详细讲对Data Model的重构与规范化处理。但基本的原则是对每一个model配备一个存取器,里面能够提供fetchALlfetchAllUsingPredicatecreateInstancesave等操做,每一个model均可以使用这些操做来获取数据,而这些操做的逻辑隐藏起来,在调用的时候我不须要知道我这个model到底是存放在数据库中,仍是.plist文件中,仍是在缓存中。我只须要知道当我调用这些方法的时候,我能够获取到我想要的model,并能够取出我想要的数据。

业务逻辑处理

在model中不仅是可以处理数据的存储,还能够对业务逻辑进行处理。在我须要重构的项目中,不管是强弱业务逻辑都有散落在vc的状况,致使了vc十分臃肿,以下面的代码中,就是须要实现从DateModel中取出一个时间,将NSDate格式的时间转换到NSString,并在View中展现出来的状况:

DateModel.h

@interface DateModel : BaseModel

@property (copy, nonatomic) NSDate *currentDate;

@end

DateModel.m

- (instantcetype)init
{
    if (self = [super init])
        currentDate = [NSDate date];
    return self;
}

aViewController.m

- (void)showTheDate
{
    DateModel *dateModel = [DateModel new];
    NSDate *date = dateModel.currentDate;

    NSDateFormatter *format = [[NSDateFormatter alloc] init];
    format.dateFormat = @"yyyy年MM月dd号 HH:mm:ss";
    NSString *string = [format stringFromDate:date];

    self.dateLabel.text = string;
}

事实上这段代码彻底能够分开放置在model层中,让整个vc的代码更加清晰,如:

NSDate+dateTransform.h

@interface NSDate (dateTransform)

+ (NSString *)transformStringFromDate:(NSDate *)date;

@end

NSDate+dateTransform.m

+ (NSString *)transformStringFromDate:(NSDate *)date
{
    NSDateFormatter *format = [[NSDateFormatter alloc] init];
    format.dateFormat = @"yyyy年MM月dd号 HH:mm:ss";
    NSString *string = [format stringFromDate:date];

    return string;
}

建立一个NSDate的分类并将转换的代码放到其中,并由DateModel调用他来完成转换

DateModel.h

@interface DateModel : BaseModel

@property (copy, nonatomic) NSString *currentDate;

@end

DateModel.m

- (instantcetype)init
{
    if (self = [super init])
    {
        currentDate = [NSDate transformStringFromDate:[NSDate date]];
    }
    return self;
}

而后在vc中,咱们只须要简单的调用:

aViewController.m

- (void)showTheDate
{
    DateModel *dateModel = [DateModel new];
    self.dateLabel.text = dateModel.currentDate;
}

这样整个vc的代码结构就清晰了不少,model层取出的属性也能直接交付到view层去显示,而日期转换这类代码也能轻易的被复用。总之,针对这类的model,能够把调用方法尽量的抽象,当须要解耦这部分代码的时候能够应用IOC模式,不然,在往后改变这些逻辑会变得十分困难。以上内容就是本篇的所有内容以上内容但愿对你有帮助,有被帮助到的朋友欢迎点赞,评论。若是对软件测试、接口测试、自动化测试、面试经验交流。感兴趣能够关注我,咱们会有同行一块儿技术交流哦。

相关文章
相关标签/搜索