OO / DTO Architecture question

Question

We have an entity (class) containing data and methods (lets call it Person). There are other classes that need to use the data in this object (let's call one of them Accountant), but do not need to use the functionality in it's methods.

Would it be better to send the entire Person object to Accountant, or to create a new PersonData object just to hold the data and send that to the Accountant obj?

We do have one case we need to figure this out for, but I'd like to know the best general answer so we can utilize it throughout.

Answer 1

Generally, you would hand off a DTO where you need to consume the data in some serialized form - so over a web service or in a smart client for example. If you're just using the Person object within the domain, and you have encapsulated properly, why go to the effort of creating a DTO?

Answer 2

I would say that OOP would have you use 'get' methods as defined within the person class. I wouldn't sent the whole object as accountant doesn't need the whole object, just the selective data. I would say not the latter as you are creating massive redundancy that is unnecessary.

But then OOP like this is highly idealized, so it may well be better to do it another way...

Answer 3

I generally reserve use of DTOs for cross layer transmission of data. If this is not the case, I'm not sure of a compelling reason to create one.

Answer 4

I think this a question of trust boundaries. On a business application, trust boundaries usually dictate your layer architecture. If your "Accountant" is outside Person's trust boundary, then there should be some kind of model transformation. The architecture and the requirements should dictate what kind of transformation.

Answer 5

as stated by others, there's no real point in using DTOs except if there's no transfer involved ... :)

the solution I'd propose, would be to abstract the object passed to Accountant to an interface IAccountee and have Person implement it ... I'm not familiar with C# (from your profile, I infered that's your language of choice :) ), but this should probably point you to the right direction:

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
}

basically, that's the D in SOLID :) ... it's flexible and clean and also avoids sharing unnecessary information from Person with Accountant ...

as far as I understand, C# interfaces cannot require variables (as in most languages), which forces you to create accessors (unless there is some language/IDE feature to generate default plain accessors) if you haven't done so yet ... it's a little more time consuming than using plain variables, and requires more performance than a plain field access, but OTOH, it's also what I'd consider good practice, at least when things aren't getting performance ... I think it's definitely more elegant than creating an extra DTO-class and copying data back and forth (or at least in one direction) ...

hope that helps ... ;)