CODEWITHSUNDEEP
asp.net-mvcentity-frameworkentity-framework-6domain-driven-designcqrs
Jaime Sangcap
Jaime Sangcap

Reputation: 2595

How to design UI Model when using Aggregate with ID reference only to another Aggregate

I've read Vaughn's(author of Red Book) 3 part series of Effective Aggregate Design here

Given this code:

public class Transaction
{
            public Guid Id { get; private set; }
            public int Number { get; private set; }
            public DateTime Date { get; private set; }
            public Guid ClientId { get; private set; } // other aggregate reference by ID only
            public Guid BranchId { get; private set; } // other aggregate reference by ID only
            public ICollection<TransactionItem> LineItems { get; private set; }
}

Now in the UI, if I want to display also the Branch.Name and the Client.FullName & Client.Company.Name

Should I create flat ViewModel?

public class ViewModel
{
     // other transaction properties

     public string ClientName {get;set;}
     public string ClientCompanyName {get;set;}
     public string BranchName {get;set;}
}

or ViewModel with complex type?

public class ViewModel
{
     // other transaction properties

     public ClientDto { get; set; } // companyName and other details inside
     public string BranchName {get;set;}
}

or is there any better way of doing it? As much as possible I want to write less code but still keeping my Domain Model clean.

Right now Im writing raw sql (database views) and mapping the result to ViewModel, sometimes Im mapping to database view and create mapping in order for Entity Framework to materialize the result to viewmodel.

I also need to give alias to the fields being returned by my views in order to avoid name clash.

But neither feels right because of the amount of code

Does using database/raw sql is the way to go?

Can AutoMapper help me with this?

If you can share how you're doing it, Im also interested to see your code.

Upvotes: 0

Views: 104

Answers (1)

plalx
plalx

Reputation: 43728

"Does using database/raw sql is the way to go?"

That would refer to an architecture called CQRS employed by many today which is based on the premise that commands and queries are different problems that should be solved by different solutions. A single unified model will often have to be streched both ways and will end up being less maintainable, focused and performant than having two models.

The domain model is optimized for processing commands so it's normal that trying to query it is painful. You often end up having to call upon many repositories just to construct a moderately complex view-model.

However, you will often read that CQRS is bound to Event Sourcing and having a Command Bus, a different read database updated through projections and having to process commands asynchronously. If you are building a system that is highly concurrent then you may benefit all these patterns, but most systems will never need that and using these techniques will introduce accidental complexity. Here's an interesting article about CQRS Myths.

If you are using a RDBMS then I suggest that you simply bypass the domain model for queries, but not have a seperate read database.

Also, regarding your flat-vs-unflattened view-model question I would opt for the representation that is most practical for consumers. However, I favor an unflattened structure because it allows you to create meaningful wholes (group highly cohesive data). It may also be easier to construct more complex view-models from existing view-models by composing them together.

Upvotes: 2

Related Questions