MVC / MVP 中的验证
我是 MVC / MVP 的新手，并通过创建 Winform 应用程序来学习它。
我在某种程度上创建了模型、演示者和视图……现在我的验证适合在哪里。
我认为初始数据类型验证（例如年龄字段中的数字）应该通过视图完成。而其他验证（例如年龄是否在 200 岁以内）应通过模型完成。
关于数据类型验证，我的视图将值公开为属性，
public int? Age
{
get
{
int val;
if (Int32.TryParse(TbxAge.Text, out val))
{
return val;
}
return null;
}
set
{
TbxAge.Text = value;
}
}
我可以单独执行验证，但是当演示者尝试访问属性 Age 时，如何通知演示者验证仍处于挂起状态？特别是当该字段是可选的时。
抛出一个validationpending异常是不是很好，但是演示者必须在每个点捕获它。
我的理解是否正确，或者我错过了什么。
更新（为了清楚起见）：在这个简单的情况下，年龄字段是可选的，当用户输入他的名字而不是数字时我应该做什么。 我不能传递 null，因为这意味着该字段已被用户留空。那么我如何通知演示者输入了无效数据......
I'm new to MVC / MVP and learning it by creating a Winform application.
I have to some extent created the Models, Presenters and Views... Now where do my validations fit.
I think the initial datatype validation (like only numbers in Age field), should be done by view. Whereas the other validations (like whether age is within 200) should be done by model.
Regarding datatype validation, my view exposes the values as properties
public int? Age
{
get
{
int val;
if (Int32.TryParse(TbxAge.Text, out val))
{
return val;
}
return null;
}
set
{
TbxAge.Text = value;
}
}
I can perform validation seperately, but how do I inform presenter that validation is still pending, when it tries to access the property Age ?. Particularly when the field is optional.
Is it good to throw a validationpending exception, but then the presenter must catch it at every point.
Is my understanding correct, or am I missing something.
Update (for the sake of clarity) : In this simple case where the age field is optional, What should I do when the user typed his name instead of a number. I cant pass null as that would mean the field has been left empty by the user. So how do I inform the presenter that an invalid data has been entered...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
从 MVP 方面来看（我相信它更适合 WinForms），您的问题的答案是有争议的。然而，我理解的关键是，你应该可以随时改变你的观点。也就是说，我应该能够提供一个新的 WinForms 视图来显示您的应用程序或将其连接到 ASP.NET MVC 前端。
一旦你意识到这一点，验证就变得很明显了。应用程序本身（业务逻辑）应该抛出异常、处理错误等等。 UI逻辑应该是愚蠢的。换句话说，对于 WinForms 视图，您应该确保该字段不为空，等等。许多控件属性都允许这样做 - Visual Studio 的属性面板。在 GUI 中对抛出异常之类的代码进行验证是一个很大的禁忌。如果您要对视图和模型进行验证，那么您将复制代码 - 您所需要的只是一些简单的验证，例如控件不为空。让实际应用程序本身执行实际验证。
想象一下，如果我将您的视图切换到 ASP.NET MVC 前端。我不会说控件，因此需要某种形式的客户端脚本。我要表达的观点是，您需要编写的唯一代码是针对视图的 - 也就是说，不要尝试跨视图推广 UI 验证，因为这会违背分离您的关注点的目的。
您的核心应用程序应该包含所有逻辑。每个视图的专用视图逻辑（WinForms 属性、Javascript 等）应该是唯一的。在我看来，拥有每个视图都必须验证的属性和接口是错误的。
Coming from the MVP side (I believe it's more appropriate for WinForms) the answer to your question is debatable. However the key for my understanding was that at anytime you should be able to change your view. That is, I should be able to provide a new WinForms view to display your application or hook it upto a ASP.NET MVC frontend.
Once you realise this, the validation becomes aparant. The application itself (the business logic) should throw exceptions, handle errors and so forth. The UI logic should be dumb. In other words, for a WinForms view you should ensure the field is not empty, or so forth. A lot of the properties for the controls allow this - the properties panel of Visual Studio. Coding validation in the GUI for the likes of throwing exceptions is a big no no. If you were to have validation on both the view and the model you'd be duplicating code - all you require is some simple validation such as controls not being empty for example. Let the actual application itself perform the actual validation.
Imagine if I switched your view to a ASP.NET MVC front end. I would not have said controls, and thus some form of client side scripting would be required. The point I'm making is that the only code you should need to write is for the views - that is do not try to generalise the UI validation across views as it will defeat the purpose of separating your concerns.
Your core application should have all your logic within it. The specalised view logic (WinForms properties, Javascript etc...) should be unique per view. Having properties and interfaces that each view must validate against is wrong in my opinion.
如果您的“视图将值公开为属性”，我怀疑您遗漏了某些内容。 MVP/MVC 和其他一些 UI 解耦模式之间的主要区别在于它们包含一个模型，该模型旨在成为视图和呈现器或控制器共享的数据的主要容器。
如果您使用模型作为数据容器，验证的责任就变得非常明确。由于只有呈现器（或控制器）实际上除了显示数据之外还执行其他操作，因此它负责验证数据是否处于其即将执行的操作的可接受状态。
在编辑过程中向编辑器表单/窗口添加数据验证问题的视觉指示器当然是件好事。然而，它应该被认为或多或少相当于视图“养眼的糖果”，并且它应该被视为真实验证逻辑的附加组件（即使它基于共享元数据或代码）。呈现者（或控制器）应保留数据有效性的真正权威，并且其验证代码不应托管在视图中。
If your "view exposes the values as properties", I suspect that you are missing something. The principal distinction between MVP/MVC and some of the other UI decoupling patterns is that they include a model, which is intended to be the main container for data shared by the view and presenter or controller.
If you are using the model as a data container, the responsibility for validation becomes quite clear. Since only the presenter (or controller) actually does anything besides display the data, it is the one responsible for verifying that the data is in an acceptable state for the operation which it is about to perform.
Addition of visual indicators of data validation problems to an editor form/window during editing is certainly nice to have. However, it should be considered more or less equivalent to view "eye candy", and it should be treated as an add-on to the real validation logic (even if it is based on shared metadata or code). The presenter (or controller) should remain the true authority for data validity, and its validation code should not be hosted in the view.
我相信视图验证仅与 javascript 相关，因为视图不会在发布时运行任何代码，只有控制器会运行。
但我也永远不会相信 javascript 验证，因为恶意用户可以绕过它，或者无知的用户可能禁用 JS，因此在控制器的服务器端代码中重复任何 JS 验证。
不过，该视图可能有显示任何错误的方法。
I believe view validation is only relevant in javascript as the view does not run any code on post, only the controller does.
But I would also not ever trust javascript validation as a malicious user could bypass it or an ignorant user might have JS disabled so repeat any JS validation in serverside code in the controller.
The view might have means to display any errors though .