1

I was reading this blog post and liked the idea of using the DTO class for an entity and using it as a property in the corresponding business object class like so:

public class Person : BALBase
{
        public PersonDTO Data { get; set; }

This also can eliminate the need for a mapping tool like AutoMapper (mapping between POCO and DTO). I am thinking of using this concept in my app. My app is layered using straight assemblies with no web services/REST/WCF calls.

What can be the disadvantages of using this concept?

Tony_Henrich
  • 565
  • 4
  • 7
  • why not let DTO and entity BO objects be one class? I don't see any disadvantage at all. Business actions can be performed by separated BO objects that are not DTO – InformedA Jun 15 '14 at 09:37

2 Answers2

3

The main disadvantage of this method is that you're losing any business logic and validation that your business object might enforce over the data.

What does the Person class do that the PersonDTO doesn't? Perhaps it performs validations on fields, so that setting Person.Name to an empty string is caught and an error returned. Exposing PersonDTO directly would miss that.

Perhaps the business object ensures that proper workflows are maintained. Moving a person from one department to another might require approval of a manager in the target department. Person might expose a MoveDepartment method that encapsulates this workflow logic, while exposing PersonDTO might allow a caller to change PersonDTO.Department directly.

Avner Shahar-Kashtan
  • 9,166
  • 3
  • 29
  • 37
  • @randomA In this case, why even expose the DTO? – Avner Shahar-Kashtan Jun 15 '14 at 10:12
  • The OP asks about exposing his DTO as a property in his BO object, rather than exposing the properties individually. – Avner Shahar-Kashtan Jun 15 '14 at 10:21
  • @Avner The BO has more properties, validation & business rules logic in it.. like the article shows. The DTO and BO are not mirror images of each other. The BO works as usual. You're just accessing the data properties as BO.Data.Property instead of BO.Proeprty and these properties have been set in a single operation – Tony_Henrich Jun 15 '14 at 16:59
  • @Tony_Henrich But if you're allowing the caller to bypass the BO, aren't you potentially allowing business logic to be bypassed? The DTO has a `Department` property that should *only* be set in specific circumstances. That's the business logic. What happens when someone sets it in the DTO? – Avner Shahar-Kashtan Jun 15 '14 at 17:35
0

One major problem I see is that dependency is the wrong way. DTO should depend on your business layer, not other way around. It is much more possible to change DTO than it is to change business rules.

What if you want to have different type of DTO for different services? What if you want to use the business layer directly in webservice? Constraining your business layer to use one specific DTO will make all of those cases harder to implement.

Euphoric
  • 36,735
  • 6
  • 78
  • 110
  • The DTO is just a class with properties. It's not aware of the DAL being used and it doesn't care. Another layer like a repository hydrates the DTO. My app is not complex enough to have several different DTO's for the same BO. For example, a person class is the same everywhere. If I add a new column in the Person table in the database and add it in the DTO, the BO automatically gets it. For a non complex app, this seems like a time saver. I also mentioned that I am not using any kind of services. Just straight assemblies with no remote calls. – Tony_Henrich Jun 15 '14 at 17:07