在 VB.NET 中使用数据注释属性寻求 ASP.NET MVC 模型验证的建议答案

【问题标题】：Seeking advice on ASP.NET MVC model validation with data annotation attributes in VB.NET在 VB.NET 中使用数据注释属性寻求 ASP.NET MVC 模型验证的建议
【发布时间】：2011-07-04 15:51:47
【问题描述】：

所以经过一些实验后，我惊讶地发现这是完全可以接受的，因为 MVC 不会抱怨我受保护的内部抽象元数据类，并且模型验证仍然有效：

部分域对象，由工具生成：

Partial Public Class SampleDomainObject

    Private _id As Integer
    Private _customCode As String
    Private _description As String

    Public Property ID() As Integer
        Get
            Return Me._id
        End Get
        Set(ByVal value As Integer)
            Me._id = value
        End Set
    End Property

    Public Property CustomCode() As String
        Get
            Return Me._customCode
        End Get
        Set(ByVal value As String)
            Me._customCode = value
        End Set
    End Property

    Public Property Description() As String
        Get
            Return Me._description
        End Get
        Set(ByVal value As String)
            Me._description = value
        End Set
    End Property

End Class

部分域对象，元数据实现

<MetadataType(GetType(SampleDomainObject.Metadata))> _
Partial Public Class SampleDomainObject

    Protected Friend MustInherit Class Metadata

        <HiddenInput()> _
        Public MustOverride Property ID() As Object

        <Required(), _
        StringLengthRange(4), _
        DisplayName("Custom Code")> _
        Public MustOverride Property CustomCode() As Object

        <Required(), _
        StringLength(255)> _
        Public MustOverride Property Description() As Object

    End Class

End Class

我这样做是因为我不想在 VB.NET 中为 Metadata 类实现具有支持字段、getter 和 setter 的实际属性，以将维护降至最低（我在 .NET 3.5 上，我没有自动属性）。

我担心的是，拥有一个受保护的抽象内部类可能会使其他人在 MVC 之外使用此域对象（我的域对象是共享数据访问框架的一部分）感到困惑。

所以我的问题是，在 MVC 最佳实践领域，这是否可以接受？还聪明？我是 MVC 新人，所以我会接受我能得到的任何反馈。

谢谢！

【问题讨论】：

标签： asp.net-mvc vb.net validation .net-3.5 data-annotations

【解决方案1】：

在使用 RIA 服务的 Silverlight 应用程序中，元数据类看起来非常相似，但没有 MustInherit。我怀疑您的实践遵循了适当的良好实践，即使在 MVC 的上下文之外，考虑到可以通过 MVC 和域服务看到该行为。

我昨天问了一个相关的问题。答案描述了这种伙伴类策略如何在域类是代码生成的情况下有效地工作。 Buddy 类提供防止代码生成覆盖的保护。（见Why are buddy classes used for validation?。）

【讨论】：

【解决方案2】：

可以接受吗？对于一些。聪明的？没有。

使用 ViewModel 模式要好得多。您的业务/领域/核心逻辑不应向外指向视图和 UI 层。视图和 UI 层应指向您的业务/域/核心逻辑。

即使没有自动属性，制作视图模型的成本仍然非常低，并且确实提高了代码的质量。

此外，除非您的应用程序本质上是微不足道的，否则我相信您会发现伙伴课程无法解决问题的情况。一个很好的例子是添加和编辑场景有不同的要求。想到了用户密码字段。

【讨论】：