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
,班级信息对应的是StudentClassModel
。
另一方面,在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中存储的数据类型,也方便日后的扩展与维护。
// 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配备一个存取器,里面可以提供fetchALl
、fetchAllUsingPredicate
、createInstance
、save
等操作,每个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模式,否则,在日后改变这些逻辑会变得十分困难。
以上内容就是本篇的全部内容以上内容希望对你有帮助,有被帮助到的朋友欢迎点赞,评论。
如果对软件测试、接口测试、自动化测试、面试经验交流。感兴趣可以关注我,我们会有同行一起技术交流哦。