Separate View and ViewModel in different projects of a solution

PeterKleinPeterKlein USMember ✭✭
edited January 2017 in Xamarin.Forms

Until now we have been working and been very satisfied with the Prism approach for MVVM. Our last large project (WINRT) had analogue to the Adventureworks example, two separate projects (next to some other, but that is irrelevant in this case). One for the Views and one for the Viewmodels. They were "connected" via the ViewModelLocationProvider, that was part of the Prism.Mvvm framework.

Now we have tried to use Prism in a new project and started of with the Prism Template by Brian Lagunas. We notice that Views and Viewmodels are together in the same PCL project. We could not find any substitute for the viewmodellocationprovider.

We want to separate the views from the viewmodels. Two separate teams work on respectively the UI-design in XAML for the views, whereas another team works on the business logic in Viewmodels.

How can the same approach be implemented?

Regards,

Peter

Best Answer

Answers

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    @PeterKlein

    We want to separate the views from the viewmodels. Two separate teams work on respectively the UI-design in XAML for the views, whereas another team works on the business logic in Viewmodels.

    Why do the two need to be in completely different projects for the UI designers to do their part seperately from the coders doing theirs? Those of us from WPF world where all this started have had UI people working on XAML while we work on .cs, for over 10 years.

    It shouldn't be a problem for one person to work the .XAML and even the .xaml.cs while another works the ViewModel: They're completely different files. No different than Bob working the GpsVM.cs and Gary working the UserVM.cs

  • PeterKleinPeterKlein USMember ✭✭

    @BrianLagunas said:
    Of course! You have two options:

    1. Change the conventions of the ViewModelLocator as described in this post: http://brianlagunas.com/getting-started-prisms-new-viewmodellocator/
    2. Use the Container.RegisterTypeForNavigation<View,ViewModel>() method. This is recommended as it does not rely on reflection and will be better performing.

    @Brian, I will certainly check out this article and trust that we will come to our desired solution architecture.

    @ChrisStLaurent: I know that technically speaking you're right, but what we want to keep is the architecture that has proven to be stable. The two teams tend to (test)compile in their own pace and we do not want version hassle already during desing/develop phase, even before anything is installed at our customers locations.

    Thank you both!

    Peter

Sign In or Register to comment.