因此经过一些实验后,我很惊讶地发现这是完全可以接受的,因为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中为元数据类实现支持字段,getter和setter的实际属性,以便将维护保持在最低限度(我在.NET 3.5上,我没有自动属性。)
我担心的是,拥有受保护的抽象内部类可能会让使用MVC之外的域对象的其他人感到困惑(我的域对象是共享数据访问框架的一部分)。
所以我的问题是,在MVC最佳实践的世界中,这是可以接受的吗?甚至聪明?我是MVC的新人,所以我会收到任何反馈。
谢谢!
答案 0 :(得分:0)
在使用RIA服务的Silverlight应用程序中,元数据类看起来非常相似,减去 MustInherit 。考虑到MVC 和 域名服务可以看到行为,我怀疑你的做法遵循适当的良好做法,甚至在MVC的上下文之外。
昨天我问了一个相关的问题。答案描述了这种伙伴类策略在域类是代码生成的情况下如何有效地工作。好友类可以防止代码覆盖。 (见Why are buddy classes used for validation?。)
答案 1 :(得分:0)
可接受?对于一些。聪明?不。
使用ViewModel模式要好得多。您的业务/域/核心逻辑不应指向视图和UI层。视图和UI层应指向您的业务/域/核心逻辑。
即使没有自动属性,制作视图模型的成本仍然非常低,并且确实提高了代码的质量。
除非您的申请本质上是微不足道的,否则我相信你会发现哥们班不会削减它的情况。一个很好的例子是对添加和编辑方案有不同的要求。想到用户密码字段。