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

Get certified in Microsoft Fabric—for free! For a limited time, get a free DP-600 exam voucher to use by the end of 2024. Register 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
November Carousel

Fabric Community Update - November 2024

Find out what's new and trending in the Fabric Community.

Live Sessions with Fabric DB

Be one of the first to start using Fabric Databases

Starting December 3, join live sessions with database experts and the Fabric product team to learn just how easy it is to get started.

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! Early Bird pricing ends December 9th.

Nov PBI Update Carousel

Power BI Monthly Update - November 2024

Check out the November 2024 Power BI update to learn about new features.