Implement Clean Mvvm Architecture

[Goncharuk-Nikita]

Hi, I’m looking for Mvvm plugins for Unity and your solution is currently the best I've found.

I worked with Mvvm for over a year on Xamarin technology and clearly understand its work. But what you have is different from pure Mvvm. I look at MvvmCross and this is a great example for me of cross-platform Mvvm.

I think this framework could be partially ported to Unity. MvvmCross Unity3d. Now I am trying to implement something similar in Unity in a new project, but I have to write it on the go. The concept of what I am writing is very similar to the MvvmCross, excluding the View part.

Below I gave an example of running my program in Unity.

My ViewModels are pure C # classes, they are inherited from the ViewModelclass, which implements the underlying logiс. My Views- MonoBehaviour, are inherited from the base Viewclass, which implements the basic logic and events.

I try to implement ViewModel-first navigation andcreate a basic asynchronius (UniRx with UniTask) NavigationService to navigate between ViewModels. In GameSettings, I defined Views (which are represented as an AssetReference using the AddressableSystem) and the name ViewModel. For some connection. NavigationService has a Load method that loads the entire View asynchronously and attaches a ViewModel to them. Yea, thats ViewModel-first :)

On Start:

1. I use Zenject to register services and my ViewModels.
2. Then i run LoadingViewModel. And call NavigationService.Load
3. Navigate to some MainViewModel

View class like a MyPage.xaml.cs it needs to bind texts, buttons and etc. to ViewModel:

For text binding i use ReactiveProperty from UniRx.

But my bindings are frankly shit. And I want to implement Fluet binding method from MvvmCross.

What is this post / question for. I'm looking for people who want to do something like this. Ideally, I want to migrate MvvmCross to Unity. If it will be interesting to you, then I can provide a more detailed implementation of my approach, but it is not perfect and mainly depends on external plug-ins.

Thanks

[RoryDungan]

Hey so first off I should clarify - are you asking specifically about making a navigation system with Unity Weld, making Unity Weld work with MvvmCross, or making a new framework that's like MvvmCross but works in Unity, possibly with some code from Unity Weld?

In regards to not being pure MVVM, our examples typically have a MonoBehaviour as the ViewModel just because that's easy to set up, but the system is designed to support pure C# classes as ViewModels too. You can do this by having a MonoBehaviour that implements IViewModelProvider and just returns your real ViewModel. If you're using Zenject I imagine it should be fairly simple to create a MonoBehaviour that implements IViewModelProvider and uses Zenject to resolve the dependency on the ViewModel class.

I had a look at the Fluent binding syntax from MvvmCross and it does look pretty cool but it's probably outside the scope of Unity Weld. Unity Weld is explicitly designed to enable designers to set up bindings in the editor without needing to write any code, while that is a completely code-driven binding system. Unity Weld is also based entirely on reflection and bindings stored as strings which might not fit well with their strongly typed system. If you just wanted to make MvvmCross work with Unity then it's possible you might be able to reuse some of our binding code though.

[Goncharuk-Nikita]

Thank you for your detailed answer. I cited as an example MvvmCross as a completely architectural environment that not only gives you the ability to bind, but the full life cycle of the application. I plan to further understand this direction, because Mvvm + ECS seems to me a very good idea. Since MvvmCross is open source, then for a start I plan to write something similar that will cover launching the application, navigating through scenes and Views.

As for the Fluent bindings, it seems to me that this provides great opportunities and performance gains. And orientation to designers is really a great advantage. However, this is really a separate and fairly voluminous topic.

I also want to suggest that you slightly simplify the creation of properties in the ViewModel by creating a base ViewModel based on the Bindable class.

Creating properties in the ViewModel will be cleaner, without checking for if (value == _name) and OnPropertyChanged calls.

Something like this: