Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 

Be one of the first to start using Fabric Databases. View on-demand sessions with database experts and the Microsoft product team to learn just how easy it is to get started. Watch now

Reply
RobertSlattery
Resolver III
Resolver III

Seperation of concerns in Power BI

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?

1 ACCEPTED SOLUTION
Greg_Deckler
Super User
Super User

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).



Follow on LinkedIn
@ me in replies or I'll lose your thread!!!
Instead of a Kudo, please vote for this idea
Become an expert!: Enterprise DNA
External Tools: MSHGQM
YouTube Channel!: Microsoft Hates Greg
Latest book!:
Power BI Cookbook Third Edition (Color)

DAX is easy, CALCULATE makes DAX hard...

View solution in original post

2 REPLIES 2
Greg_Deckler
Super User
Super User

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).



Follow on LinkedIn
@ me in replies or I'll lose your thread!!!
Instead of a Kudo, please vote for this idea
Become an expert!: Enterprise DNA
External Tools: MSHGQM
YouTube Channel!: Microsoft Hates Greg
Latest book!:
Power BI Cookbook Third Edition (Color)

DAX is easy, CALCULATE makes DAX hard...

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.

Helpful resources

Announcements
Las Vegas 2025

Join us at the Microsoft Fabric Community Conference

March 31 - April 2, 2025, in Las Vegas, Nevada. Use code MSCUST for a $150 discount!

Dec Fabric Community Survey

We want your feedback!

Your insights matter. That’s why we created a quick survey to learn about your experience finding answers to technical questions.

ArunFabCon

Microsoft Fabric Community Conference 2025

Arun Ulag shares exciting details about the Microsoft Fabric Conference 2025, which will be held in Las Vegas, NV.

December 2024

A Year in Review - December 2024

Find out what content was popular in the Fabric community during 2024.