Seperation of concerns in Power BI

[RobertSlattery]

I'm looking for guidance on how to think about power bi applications from an architectural point of view. 

My starting point for this was confusion about Power Query Language (M) vs DAX and Relationships and what should be good practice about when to use which.

My thinking so far is that Power Query, including functions to pull data from native SQL queries if required, written in the M language, is the equivalent of the Controller (or maybe the Model, I'm unsure) in MVC or the View Model in MVVM. The View is pretty clearly Power View, including Relationships measures and DAX.

The most important thing is to maintain separation of concerns and minimize coupling between these two domains but it would be good to be able to map the wider, well established architectural principles into the Power BI space.

Can anybody offer thoughts and guidance on this?

[Greg_Deckler · Accepted solution]

I'm not sold on using application design patterns to model Power BI behavior but you could look at it a number of different ways:

• Power Query (M) and Relationships create the Model
• DAX can manipulate the model by adding Columns and Measures and is thus the Controller
• Reports and dashboards are Views

In MVVM it would be:

• Power Query (M) and Relationships create the Model
• DAX creates a View Model
• Reports and dashboards are Views

All of that being said, Power BI is not a traditional application development platform and thus I do not think those kinds of concepts are really applicable or even very useful. In addition, Power BI was conceived as a self-service BI platform where one person is essentially doing everything. You should also look into the concept of Apps (Organizational Content Packs).

[RobertSlattery]

Thanks that helps me a lot.

I was thinking along similar lines but it helps to have confirmation.

 The only difference I had was that Relationships belong with DAX in the View Model maybe.

I'm interested in your statement about relevance.

First of all, wouldn't you call them architectural structures rather than design patterns?  And if your not sold on that, what would you offer as an alternative approach?  If not using MVVM for example, how do you reason about architecture and how do we, new users make sense of all of the options for doing what looks like the same thing?

For example, why would you use Relationships instead of M to shape the model?

When would you ever use a calculated column instead of Table.AddColumn in M?

What is the basis for deciding whether to use DAX or M?

What framework would you use to explain it?

Also, modular models seems like a useful thing which would also support separation of concerns.