Starting December 3, join live sessions with database experts and the Microsoft product team to learn just how easy it is to get started
Learn moreGet 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
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?
Solved! Go to 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:
In MVVM it would be:
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).
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:
In MVVM it would be:
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).
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.
Starting December 3, join live sessions with database experts and the Fabric product team to learn just how easy it is to get started.
March 31 - April 2, 2025, in Las Vegas, Nevada. Use code MSCUST for a $150 discount! Early Bird pricing ends December 9th.
User | Count |
---|---|
87 | |
83 | |
82 | |
67 | |
49 |
User | Count |
---|---|
135 | |
111 | |
100 | |
65 | |
62 |