Hi, I am using dumb business objects in my application. Just used a DTO to transfer selected properties of object but I am wondering what is the difference between the two ? I cant find any.
+1
A:
I would say that the only difference is that of intent, assuming your dumb business objects only hold state and no behavior.
In that context:
- DTOs are intended to transfer data between application layers
- Dumb Business Objects are part of your domain model
Oded
2010-07-10 17:36:09
Actually I used a DTO for binding an object which had about 30 fields, but I couldnt find any difference between my DTO and the BO itself only less fields/attributes. Are DTO's recommended in this case as I have now redundancy in my project ?
Popo
2010-07-10 17:40:52
@Popo - Completely up to you. What makes sense to your application? Are you using the two in similar capacities? Do they have the same responsibilities? Are the DTOs there for decoupling?
Oded
2010-07-10 17:44:11
Hmm, ok. I am using them right now just to reduce memory wastage in case of large BO's. One thing more, if you were me would you have used a DTO for this purpose ?
Popo
2010-07-10 17:49:39
@Popo - it really depends on the complexity of the application and the need to separate concerns. In the case of BO's that have large amounts of data that is not required (for instance a large binary field), then using a DTO for this specific need sounds like a good thing.
Oded
2010-07-10 17:52:49
Thanks, needed to confirm from experts.
Popo
2010-07-10 17:56:55
@Popo: Take a look at the Anemic Domain Model anti-pattern (http://www.martinfowler.com/bliki/AnemicDomainModel.html). That might be what you're struggling with.
Justin R.
2010-07-10 19:09:30
+1
A:
Maybe a little redundant, but I already typed it so hey ;)
To oversimplify (a lot), the business objects should have getter / setter methods, and the DTO should just have properties. The business objects need to obey you business rules, but the DTOs are just for transferring data; they don't need to obey any rules and should be designed to get data in and out of them as quickly as possible.
In a weakly-typed language like PHP DTOs are not always necessary as arbitrary properties can be given to generic objects on the fly. They can still be useful for documentation, though, and strongly-typed function parameters.
no
2010-07-10 17:52:32
Thanks for the detailed reply. I am beginning to get the hang of things now =) Thank you.
Popo
2010-07-10 17:55:58
In C#, each property is essentially a getter/setter pair. In this respect, your answer does not make much sense in the C# realm.
Oded
2010-07-10 18:12:04
@Oded: I think the answer made sense. I believe his point is that the business object should control the data that the DTOs contain. By using getter and setter methods rather than properties, callers are more likely to assume that their data is being *processed* rather than simply being stored.
Justin R.
2010-07-10 19:06:59
@Justin: Doing it that way -- `SetFoo(42)` rather than `Foo = 42` -- wouldn't be idiomatic C#. The only time I'd expect to see that in a well-written C# codebase would be if it was a port from another language, where the author wanted to maintain a consistent API between the different languages.
LukeH
2010-07-10 22:45:34
A:
When you say "dumb" business objects, you're effectively making those objects the same thing as a DTO. What makes a business object a business object is the addition of validation and other functional logic. I disagree with user 'no' when he says that business objects require setter and getter methods; they can use properties just fine, they just need a lot more than either one.
A common perspective is that business objects should be allowed to hold invalid values, and only throw exceptions when attempting to persist to the database, in which case properties work perfectly well. Most applications, however, want a way to provide feedback to the user before attempting to post to the database.
Rockford Lhotka's CSLA.NET approach is to use an IsValid() method on the business object, with a set of rules that have been assigned to the object itself. There are other ways to address this, but the key is that a business object performs validation. "Dumb" business objects really are just DTOs, as you suspect.
James B
2010-07-13 20:08:51