OO / DTO Архитектурный вопрос

Question

У нас есть объект (класс), содержащий данные и методы (назовем его Person). Существуют другие классы, которым необходимо использовать данные в этом объекте (давайте назовем один из них Accountant), но не нужно использовать функциональность в его методах.

Было бы лучше отправить весь объект Person бухгалтеру или создать новый объект PersonData только для хранения данных и отправить их бухгалтеру obj?

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

Answer 1

Как правило, вы должны передать DTO, где вам нужно использовать данные в какой-либо сериализованной форме - например, через веб-сервис или в смарт-клиент. Если вы просто используете объект Person в домене и правильно инкапсулировали, зачем переходить к созданию DTO?

Answer 2

, как утверждают другие, нет никакого смысла в использовании DTO, за исключением случаев, когда нет никакой передачи ...:)

решение, которое я бы предложил, состояло бы в том, чтобы абстрагировать объект, переданный Accountant в интерфейс IAccountee, и Person реализовать его ... Я не знаком с C # (из вашего профиля я это ваш выбор языка :)), но это, вероятно, должно указать вам правильное направление:

class Accountant {
    //....
    public void performAction(IAccountee target) 
    {

    }
}
interface IAccountee
{
    string Name
    {
        get;
    }
    int Salary
    {
        get;
        set;
    }
}

class Person : IAccountee
{
    //implementation here, as well as some stuff specific to Person
}

в основном это D в SOLID :) ... он гибкий и чистый, а также позволяет избежать обмена ненужной информацией из Person с Accountant ...

Насколько я понимаю, интерфейсы C # не могут требовать переменных (как в большинстве языков), что вынуждает вас создавать средства доступа (если нет какой-либо функции языка / IDE для создания простых средств доступа по умолчанию), если вы еще этого не сделали ... это немного больше времени, чем использование простых переменных, и требует большей производительности, чем простой доступ к полям, но OTOH, это также то, что я бы посчитал хорошей практикой, по крайней мере, когда производительность не достигает ... думаю, что это определенно более элегантно, чем создание дополнительного класса DTO и копирование данных туда и обратно (или, по крайней мере, в одном направлении) ...

надеюсь, это поможет ...;)

Answer 3

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

Answer 4

Я бы сказал, что в ООП вы должны использовать методы get, как определено в классе person. Я бы не отправил весь объект, так как бухгалтеру не нужен весь объект, только выборочные данные. Я бы сказал, что не последнее, поскольку вы создаете избыточность, которая не нужна.

Но тогда ООП, как это, очень идеализировано, так что может быть лучше сделать это другим способом ...

Answer 5

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