Неправильно ли создавать объекты запроса и ответа в других функциях?

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 

Doing это, кажется, работает хорошо, но какие проблемы мы могли anticpate вызвать? Или это вполне нормальная вещь? Кажется странным для нас. Спасибо за помощь.

Answer 1

Если этот код работает, а не много, это неправильно. Если он не сломался, не исправляйте его. Это, как говорится, единственное, что неправильно с этим кодом, я думаю, состоит в том, что он использует неправильные шаблоны. Это выглядит неправильно. Единственная проблема, которую она создала бы, это то, что она путала бы ад из новых сотрудников. Еще одним серьезным следствием такого способа является то, что класс теперь несет ответственность за две вещи: 1) объявление контракта с данными (2), определяющее его заполнение. Это смешение не одобряется в соответствии с принципами SOLID. Смешение обязанностей затрудняет проведение модульного тестирования и анализа последствий.

Когда я нахожу класс Request и класс Response, непосредственное предположение заключается в том, что вы, ребята, используете шаблон DTO. Предполагается, что классы являются контрактами данных из-за их соглашения об именах. Теперь, dtos должны быть просто POCOs лишены какой-либо бизнес-логики. Это значит, что вы можете поместить все такие классы в отдельную dll, а разные клиенты могут использовать общие структуры данных. Поэтому я не буду ожидать метода Invoke. Я ожидал бы, что dto будет filled на слое DAL либо с помощью handcrafted sqls в классе DAO, либо через некоторую структуру структуры orm.

С помощью ручных квадратов я ожидал бы набор классов, таких как Class ParentItemDAO с методами вроде Function Add(req As AddParentItemRequest) As AddParentItemResponse. Точно так же я ожидаю, что метод Function GetParentItemById возвращает либо бизнес-объект, либо dto.