我读过一些有关 MVC 的文章,但有一点我不清楚。该模型在实际中的作用是什么?
模型是否代表业务对象?
或者它只是一个帮助将信息从控制器发送到视图的类?
以两个业务类为例(从数据库填充数据)
Class Image
Property FileName As String
Property CreatedBy As User
End Class
Class User
Property UserName as String
End Class
“图像”将成为模型还是我应该创建一个新类?
在模型中,我应该创建一个 UserName 属性来从 User 对象中获取数据吗?
Class ImageModel
Property FileName As String
Property CreatedBy As User
ReadOnly Property UserName As String
Get
Return User.UserName
End Get
End Property
End Class
对此有很多观点,但根据我的经验,主要有两种观点:Model
:
视图模型
这是一个 POCO,仅包含显示所需的所有数据View
。数据通常由以下内容填充Controller
.
胖模型,瘦控制器
The Model
完成大部分业务工作。它包含并填充了所需的所有数据View
,并由Controller
保存数据等
MVC 之美
MVC 的美妙之处在于它是开放的!您可以选择您想要的任何类型的模型...您可以将所有数据放入ViewState
,变成一个Model
,变成一个ViewModel
其中包含一堆Model
s,无论如何。这真的取决于你。模型、视图和控制器是空白画布,可以随心所欲地使用。
我用什么
我的团队做了很多 MVC 工作,并且我们尝试了许多不同的方法。我们最终决定我们最喜欢的是胖模型,瘦控制器范例。
我相信这种模式最擅长“保持简单”和“不要重复自己”,并且绝对保持了“关注点分离”。
我们的代码的组织方式如下:
- Controllers
- 处理与 HTTP 请求相关的所有内容 - 重定向、身份验证、Web 安全、编码等。
- 将所有“输入”提供给
Model
,并给出Model
到视图。不访问业务或数据层。
- Views
- 处理所有 HTML 和 JSON 生成
- 仅访问强类型的数据
Model
- Models
- 负责进行所有更新、调用业务层和数据层、加载所有数据
- 处理所有验证和错误,并将它们返回给控制器
- 包含所需的所有数据的属性
View
,并自行填充
尽管这听起来像是 MVC 的通用原则,但很快就会发现 MVC 不需要这些原则,这就是许多项目使用其他原则的原因。
Example
这是一个例子Model
。控制器创建它,它填充自己,然后控制器将它传递给视图。
public class UsersModel
{
protected UserBusiness userBusiness = new UserBusiness();
public UsersModel(string editUserName)
{
// Load all users:
this.Users = userBusiness.GetAllUsers();
// Load the user to be edited:
this.EditUser = (editUserName == null) ? null : userBusiness.GetUser(editUserName);
}
public List<User> Users { get; private set;}
public User EditUser { get; private set; }
}
在这种情况下,所有“用户业务逻辑”都位于不同的项目(我们的“业务层”)中,因为我们有一个大型系统。但较小的项目不需要这个......模型可以包含业务逻辑,甚至数据访问代码。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)