Where does Revit API business logic goes in MVVM?

[vamsi345]

I have experience in developing Revit ExternalCommand tools. I have just started using Revit API templates while learning to create External Application Addins. So my question is that where does the business logic of Revit API goes into in MVVM architecture? for example, querying the elements and using transactions. Should they go into Model or ViewModel?

[Nice3point]

The model is the Revit document itself, and the Model-ViewModel relationship is our add-in's call to the RevitAPI. The API calls themselves, transactions, collectors, can be in the VM, this is normal, but if the VM grows and contains code responsible not only for Binding to View, it is better to transfer it to separate classes, these are just classes with business logic, but still this will not be a model. The ViewModel should contain only what is related to Binding, View only UI and binding to this VM, the Model section may not be in the plugin at all, because this is a finished Revit document that we don't need to write. For example, here https://github.com/jeremytammik/RevitLookup/blob/dev_winui/RevitLookup/ViewModels/Pages/SnoopViewModel.cs the code that receives elements from the collector is called from the ViewModel, the logic is placed in a separate class to avoid duplication, but at that At the same time, you could easily call the collector directly in the VM. In my plugins, Model is most often missing, and this is normal, we are writing a plugin, not a new product

[gaborschnierer]

These articles helped me a ton, might help you @vamsi345 as well
https://stackoverflow.com/questions/50379123/wpf-datatype-unable-to-reference-3rd-party-object-type
https://mathcadbimthingys.technikstudio.com/index.php/2017/01/25/view-viewmodel-ing-for-your-wpf-windows-revit-api-with-wpf-series-33/