在其他函数中实例化请求和响应对象是不是很糟糕？

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）定义算法来填充它。根据 SOLID 原则，这种混淆是不受欢迎的。职责的混淆使得进行单元测试和影响分析变得困难。

当我找到Request 类和Response 类时，立即假设你们正在使用 DTO 模式。由于它们的命名约定，这些类被假定为数据协定。现在，dto 应该是没有任何业务逻辑的简单 POCO。这样您就可以将所有此类类放在单独的 dll 中，并且不同的客户端可以使用共享的数据结构。所以我不会期待那里的Invoke 方法。我希望 dto 在 DAL 层是 filled，可以通过 DAO 类中的手工制作的 sqls 或通过一些类似 orm 的实体框架。

使用手工制作的 sql，我希望有一组像 Class ParentItemDAO 这样的类和像 Function Add(req As AddParentItemRequest) As AddParentItemResponse 这样的方法。同样，我希望方法 Function GetParentItemById 返回业务对象或 dto。