Question

我是MVC / MVP的新手，并通过创建Winform应用程序来学习它。

我在某种程度上创建了模型，演示者和视图......现在我的验证适合哪里。

我认为初始数据类型验证（仅限Age字段中的数字）应该通过视图完成。而其他验证（如年龄是否在200以内）应由模型完成。

关于数据类型验证，我的视图将值公开为属性

public int? Age 
{ 
    get 
    { 
        int val; 
        if (Int32.TryParse(TbxAge.Text, out val))
        { 
            return val; 
        } 
        return null; 
    } 
    set 
    { 
        TbxAge.Text = value; 
    } 
}

我可以单独执行验证，但是当它尝试访问属性Age？时，如何通知演示者验证仍处于待定状态？特别是当该字段是可选的时。

抛出一个验证暂停异常是否合适，但是演示者必须在每一点抓住它。

我的理解是否正确，或者我遗失了什么。

更新（为了清晰起见）：在这个简单的情况下，年龄字段是可选的，当用户输入他的名字而不是数字时我该怎么办。 我无法传递null，因为这意味着该字段已被用户留空。那么如何通知演示者已输入无效数据...

Answer 1

来自MVP方面（我相信它更适合WinForms）你的问题的答案是值得商榷的。但是，我理解的关键是，您可以随时更改视图。也就是说，我应该能够提供一个新的WinForms视图来显示您的应用程序或将其挂钩到ASP.NET MVC前端。

一旦你意识到这一点，验证就会变得无用。应用程序本身（业务逻辑）应该抛出异常，处理错误等等。 UI逻辑应该是愚蠢的。换句话说，对于WinForms视图，您应该确保该字段不为空，或者等等。控件的许多属性允许这样 - Visual Studio的属性面板。 GUI中针对抛出异常等内容进行编码验证是一个很大的问题。如果您要对视图和模型进行验证，那么您将复制代码 - 您需要的只是一些简单的验证，例如控件不为空。让实际应用程序本身执行实际验证。

想象一下，如果我将视图切换到ASP.NET MVC前端。我不会说控件，因此需要某种形式的客户端脚本。我要说的是，您需要编写的唯一代码是视图 - 不要试图在视图中推广UI验证，因为它会破坏分离您关注点的目的。

您的核心应用程序应该包含您的所有逻辑。 specalised视图逻辑（WinForms属性，Javascript等...）应该是每个视图唯一的。在我看来，拥有每个视图必须验证的属性和接口是错误的。

Answer 2

如果您的“视图将值公开为属性”，我怀疑您遗漏了某些内容。 MVP / MVC与其他一些UI解耦模式之间的主要区别在于它们包含一个模型，该模型旨在成为视图和演示者或控制器共享数据的主要容器。

如果您将模型用作数据容器，则验证的责任变得非常明确。由于除了显示数据之外，只有演示者（或控制器）实际上做了任何事情，因此负责验证数据是否处于可执行操作的可接受状态。

在编辑期间向编辑器表单/窗口添加数据验证问题的可视指示器当然是很好的。但是，它应该被视为或多或少等同于查看“eye candy”，它应该被视为真实验证逻辑的附加组件（即使它基于共享元数据或代码）。演示者（或控制器）应保持数据有效性的真正权限，其验证代码不应托管在视图中。

Answer 3

我认为视图验证仅与javascript相关，因为视图不会在帖子上运行任何代码，只有控制器会运行。

但我也不会相信javascript验证，因为恶意用户可以绕过它，或者无知的用户可能已禁用JS，因此在控制器的服务器端代码中重复任何JS验证。

视图可能会显示任何错误。

MVC / MVP中的验证

3 个答案: