Reputation: 369
So I'm currently developing an application with Xamarin.Forms. Xamarin Forms uses the MVVM pattern, and I feel somewhat comfortable using this pattern, but I do have some issues. To keep this simple, I'll use an example of a single-page application. This is how I've structured it so far:
MainView.xaml //View
MainView.xaml.cs //Code behind
MainViewModel.cs //ViewModel
DataAccessHelper //DAL layer helping me communicate with a REST-API & DB
Models
Other util classes
So for stuff like where to put the logic for populating the collections used in the view with data from the REST-API; that's pretty clear. I use the ViewModel for this, and the ViewModel communicates with my DataAccessHelper to do stuff. While a ViewModel should contain presentation logic, it's only natural to do this. However, what about authentication? This is not, in any way, related to the data presented on the screen. But it's a required step that has to be done before I can do any other requests, obviously.
So this is my question:
Should the view communicate directly with my DataAccessHelper? Say, in the constructor in the code-behind I do a direct call to my DataAcess helper to authenticate, then if that goes alright, I proceed to use the ViewModel's methods to fetch the data and populate my components? Or should I also place a method in the ViewModel that the view uses to authenticate?
I.e. this:
public partial class MainPage
{
private MainPageViewModel ViewModel
{
get { return BindingContext as MainPageViewModel; }
}
public MainPage()
{
ViewModel.Authenticate();
ViewModel.LoadCountries();
ViewModel.LoadCities();
InitializeComponent();
}
}
Versus this:
public partial class MainPage
{
private MainPageViewModel ViewModel
{
get { return BindingContext as MainPageViewModel; }
}
public MainPage()
{
var dataAccessHelper = new DataAcessHelper();
dataAccessHelper.Authenticate();
ViewModel.LoadCountries();
ViewModel.LoadCities();
InitializeComponent();
}
}
Or neither? What would be best practice here? Maybe even create an Authentication-object that can be used. This object would contain wrapper-methods for communicating with the DAL, and stuff like persisting/getting your user credentials used in the authentication-request?
Thoughts?
Upvotes: 1
Views: 1180
Reputation: 4401
Defininately option A. Always have your VM talk to your services/repositories through commands/methods. Actually, you should be injecting your AuthenticationService into your ViewModel but thats another subject.
Upvotes: 1
Reputation: 3678
This is less of a factual answer and more of an opinion on app architecture using MVVM, but here goes:
First, it goes against MVVM to have the View talking directly to anything that's not purely UI-related. No app logic, no backend calls, nada.
I would instead recommend a healthy dose of Separation of Concerns; have a login View/ViewModel that handles the process of gathering and verifying credentials, and the result of a successful validation would be a navigation to the view(s) that you are trying to gate access to. If there is a token or some other object that you need to supply to your backend services, supply that to the ViewModel's constructor (ideally using an IoC container coupled with a ViewModelLocator), and it will in turn hand that to whatever backend services it consults for Model data.
Upvotes: 1