Question

I’m working on an ASP.NET MVC site, using EF4 and Automapper. I’m making good progress, and feel fairly good for the design (considering this is my first stab at a true DDD architecture). But I’m starting to see some things that I’m not too comfortable with.

The questions I have probably relate more to my lack of experience with Automapper and DDD, so they may be fairly easy for some of you to answer and point me in the right direction. There’s also a very good chance I’m going about this completely wrong, but my direction is based on what I’m reading on here, some from searching, and some from asking my own questions. But I’m also starting to realize that some of the “advice” I’m seeing is contradictory to each other.

Quick background, my domain model is simply the generated POCOs from EF4 POCO template (anemic). These are used in my service layer, and they are also exposed to my application via the service layer. I don’t have any sort of DTO, just my anemic domain model, view models, and Automapper to map the two, per the advice I was given. This is all fine and dandy assuming they can be mapped one-to-one.

My problems come in when I have to flatten my domain models into one view model, or when I need some business logic to define a view model property.

Two examples:

Flattening

I have two models, User and UserProfile. This is a one-to-one mapping, so it already is logically flat — it’s just in two separate models. My view model needs properties of both User and UserProfile in one object. From what I’ve seen, Automapper has no easy way to do this, so what I did was extend my User POCO, adding the needed UserProfile properties to it:

public string UserName
{
    get { return UserProfile.UserName; }
}

I’m not a big fan of this as it seems to violate DRY, and may become a bit of a pain the more I have to do this.

Encapsulating business logic

I have another case where a User property isn’t stored, but rather derived, and needs to do some logic before returning a value. For example, a profile image URL will depend on whether they registered with Facebook or Twitter. So I have something like this:

public string ProfileImageUrl
{
    get
    {
        if (User.TwitterId != null)
        {
            // return Twitter profile image URL
        }
        if (User.FacebookId != null)
        {
            // return Facebook profile image URL
        }
    }
}

I’m pretty sure this isn’t something that Automapper is responsible for, but I’m not sure if this should be done with a domain model extension if I want to keep it anemic. So I’m not sure where this belongs.

I’m not completely stuck on having my domain model be anemic (I know that’s its own debate), but I do anticipate this domain model being used by multiple applications with different view models and validation.

Thank in advance.

UPDATE: In response to @jfar, my main issue with the flattening example is that it seems like this should be something Automapper should be able to do. If not, then I can live with this option. I was just looking for someone to double check my design to make sure there wasn’t a better way to do this.

My issue with the encapsulating business logic example, is that I’m violating the anemia of my domain model. In some cases, this may even need to hit the repositories to pull certain data for business logic, and this seems like a bad design to me.

The other thing I’m starting to wonder, is if I shouldn’t have a DTO layer, but I honestly don’t want to go that route either (and per the question I linked above, it seems to be more accepted not to use DTOs w/ DDD).

Answer 1

1. Flattening: You can chain your mappings together using Automapper’s ability to map to an existing object.
   Chain Example
2. Encapsulatng Business Logic: I don’t really see your problem. However, if you want Automapper to be responsible, take a look at before and after maps or custom resolvers. Custom Resolver Example