Search code examples
design-patternsarchitectureprototypedto

Software Architecture question. BL creates DTOs differently by type. Is there anything better?

I've an application that has three layers:

  1. data layer: exposes Entity Framework entities
  2. business logic layer: queries the EF model, gets entities, and should expose DTO (data transfer objects)
  3. UI layer: queries BL, gets DTOs, and view them.

Now I have an issue. Different part of my application needs the same DTO but with a little bit different fields. For simplicity suppose that one of my BL classes exposes a DTO called Person that is needed with Name and Surname once and with Name and Date Of Birth in another place.

I'd like to hear from you what you think about my simple solution. I've come that is necessary for my UI to agree with BL on a "DTO contract" so that the two layers agree on classes. In my example, I would:

a) create an abstract Person class. This class doesn't have any method or field b) create a method in BL called GetPerson that accepts, as a parameter, a Person class c) define two or more classes that derive from Person (suppose PersonName and PersonDOB) d) my UI calls GetPerson passing in the needed type (like GetPerson(typeof(PersonName))) e) BL fills in the Person class

What do you think about it? Is there any better solution? I think this is not so good but nothings better comes to my mind.

Thanks a lot. Marco

Solution

  • I have a similar architecture in my MVC2 app. What I did:

    1. BL returns a Person DTO that have Name, Surname and DoB (all those properties are a part of Person)

    2. My Views work with Models, so I create specific models for each view. I would therefore have 2 Person models, ie. one with Name and Surname, other with Name and DoB.

    The conversion between DTOs and models is done by a set of classes I call Adapters. In order to simplify code I use Automapper. This is a brilliant piece of code that will copy properties from your DTOs to Models by taking into account naming conventions and explicit configuration. Do take a look at is, as you might want to use it to populate DTOs from your EF classes.

    Summing up, I have a consistent BL without any smells (this 'give me a subclass of this type' business is a bit of smell to me), and my views are working with strongly-typed models that contain only relevant data.