Проблемы дизайна с DTO и т. Д.

Question

Я проектирую веб -приложение в C#, которое в основном общается с базой данных. Я создал DTO для каждой таблицы в базе данных. Теперь для каждой таблицы существует пользовательский класс репозитория таблицы, который выполняет все сохранение и извлечение, относящиеся к этой конкретной таблице, и я использую для этого хранимые процедуры.

В настоящее время проблема заключается в том, что некоторые хранимые процедуры фактически выполнят внутреннюю операцию соединения, а затем отправят пользовательский вывод, который представляет собой комбинацию из 2 таблиц.

Поэтому я не могу хранить данные в одном объекте DTO.

Если есть какие -либо основные операции, которые в основном выполняются на одной таблице, то все в порядке. Я могу вызвать объект Table DTO для как вставки, так и для извлечения из базы данных. Но когда соединения находятся в сохраненных процедурах, и во время определенных ситуаций мы обновляем несколько таблиц.

Как мы должны разработать приложение?

Пожалуйста помоги

Спасибо

Answer 1

Похоже, вы, возможно, захотите переосмыслить наличие DTO, который напрямую соответствует каждой таблице в базе данных.

Скорее, DTO должен соответствовать чему-то логичному в реальной модели, которая используется за веб-сайтом. Так, например, у объекта клиента может быть набор идентификаторов заказа в нем, хотя они будут логически храниться в двух таблицах в базе данных.

Нет ничего плохого (на самом деле это часто важно) иметь DTO, ссылающуюся на другие DTO, поэтому, например, у вас может быть класс клиента, который указывает на список адресных классов.

Если что -то станет более сложным, вы, скорее всего, захотите рассмотреть вопрос о внедрении другого слоя на этом этапе с истинными «доменными объектами», которые отображают ваш DTO, который от звука его является «объектами настойчивости».