在其他功能中实例化请求和响应对象是不好的

Question

我找不到类似的问题，这可能是一个愚蠢的问题，不确定，我无法弄清楚要搜索哪些关键字。

例如，我们有某种请求/响应对来访问数据库的信息（原谅我，使用VB .NET，而不是我的选择，所以我只是保持一致）

Public Class ItemAddRequest
    Public param1 As String = ""
    Public param2 As String = ""
End Class
Public Class ItemAddResponse
    Public returnParameter As MyItemObject = ""
    Public Function Invoke(req As ItemAddRequst)
        ' SQL Queries go here
        ' Build my returnParameter
    End Function
End Class

因此，这些用于前端以获取在前端显示的信息，但是在代码中使用这些信息的其他位置是为了获取该信息或添加该信息的唯一目的是不好的吗？通常，您希望将（发明的单词）模块化，并使用我的MyiteMobject的方法来做到这一点，但是我们已经有大量的事情需要更改，因此至少目前我们还没有这样做。例如，我们正在做类似的事情

Public Class ParentItemAddRequest
    Public param1 As String = ""
    Public param2 As String = ""
End Class
Public Class ParentItemAddResponse
    Public returnParameter As MyParentItemObject = ""
    Public Function Invoke(req As ParentItemAddRequest)
        ' SQL Query goes here to add parent
        ' Now also need to add a regular MyItemObject
        Dim itemReq as new ItemAddRequest()
        Dim itemResp as new ItemAddResponse()
        itemReq.param1 = 'whatever
        itemReq.param2 = 'whatever
        itemResp.Invoke(itemReq)
        me.returnParameter = itemResp.returnParameter
    End Function
End Class

这样做似乎很好，但是我们会抗议造成什么样的问题呢？还是这是完全正常的事情？对我们来说似乎很奇怪。感谢您的帮助。

Answer 1

如果此代码的工作原理比没有太多是错误的。如果它破裂了，请不要修复它。话虽如此，我认为此代码唯一错误的是它使用了错误的模式。看起来错了。它会造成的唯一问题是它会使新员工的地狱混淆。以这种方式工作的另一个严重含义是，该班级现在负责两件事（1）宣布数据合同（2）定义算法以填充它。根据坚实的原则，这种混合皱眉。职责的混合使得很难进行单位测试和影响分析。

当我找到Request类和Response类时，直接的假设是你们正在使用DTO模式。由于其命名约定，这些课程被认为是数据合同。现在，DTO应该是没有任何业务逻辑的简单的Pocos。这样，您就可以将所有此类类都放在单独的DLL中，而不同的客户端可以使用共享数据结构。因此，我不会期望那里的Invoke方法。我希望DTO是通过手工制作的DAO类或通过某些ORM类似的实体框架在DAL层处的filled。

使用手工制作的SQL，我希望使用Function Add(req As AddParentItemRequest) As AddParentItemResponse之类的方法等一组Class ParentItemDAO等类。同样，我希望 Function GetParentItemById返回业务对象或DTO。