Вопросы архитектуры OO/DTO

Question

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

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

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

Answer 1

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

Answer 2

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

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

Answer 3

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

Answer 4

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

Answer 5

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

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

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 и копирование данных вперед и назад (или, по крайней мере, в одном направлении) ...

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