最近我在学习Riverpod,我得到了不可变状态的概念。
到目前为止一切顺利。。除了在许多教程中引入了entites
。
不同的作者使用这样的术语:
- 模型
- 实体
- 状态
对我来说,我目前的理解是(曾经是?):
- model ->不带逻辑/DTO的数据包,例如:
class PersonModel {
String name = '';
int age = 0;
}
- entity -> amutableobject
class PersonEntity {
int id?; // entities are identified by id
String name = '';
int age = 0;
PersonEntity(this.name, this.age);
// entites have LOGIC
void changeName(String newName) {...}
}
- state ->不可变对象
class PersonState {
final String name;
final int age;
PersonState(this.name, this.age);
PersonState copyWith({String? name, int? age})
{
return PersonState(name ?? this.name, age ?? this.age);
}
}
然而,许多(如果不是全部)flutter架构教程将实体视为状态/不可变对象,将其从存储库传输到状态/小部件的所有层。(例如here)
问题:
在Flutter/Riverpod中,实体是没有逻辑的类,而逻辑是在应用层(服务)中实现的,这是正常和正确的方法吗?
1条答案
按热度按时间t5fffqht1#
问题是Flutter-Riverpod中真正的东西是View和State。
当作者尝试将MVC应用于Flutter-Riverpod时,他们将具有某些已知含义的标签应用于Riverpod的
State
,该标签由providers
和DTOs
组成。因此,他们称
providers
- controllers 和DTOs
- models,尽管providers
不完全是控制器,DTOs
也不完全是模型。在典型的Flutter应用程序中,90%的代码属于View,10%属于State。因此,状态-视图(或视图-状态)架构似乎非常自然和充分。试图将国家分成几个层次看起来是人为的和牵强的。