In a previous blog post I demonstrated how to implement the MVVM pattern in C++/CX, by way of a small sample app that allows the user to view the photos in their Pictures library. In this blog post I will extend the sample app so that access to the underlying data source, in this case the file system, is through a centralized data access layer. The main advantage of this approach is that a repository that accesses a data source, such as the file system, can easily be swapped out for a repository that access a different data source, such as the cloud.
The sample application can be downloaded here.
The Repository Pattern
The repository pattern separates the logic that retrieves and persists data from the business logic that acts upon that data. The repository is responsible for:
- Mediating between the data source and the business layers of the app.
- Querying the data source for data.
- Persisting changes to the data source.
This separation of business logic from the data source has benefits, including:
- Centralizing access to the underlying data source via a data access layer.
- Isolating the data access layer to support unit testing.
- Improving the code’s maintainability by separating business logic from data access logic.
For more information, see The Repository Pattern.
Implementing the Repository Pattern in C++/CX
The sample app implements the repository pattern by defining an abstract base class with pure virtual member functions, to provide a base class from which other repository classes must inherit. A pure virtual member function is a member function that is defined as virtual and is assigned to 0. Such an abstract base class can’t be used to instantiate objects and serves only to act as an interface. Therefore, if a subclass of this abstract class needs to be instantiated, it has to implement each of the virtual functions, which results in it supporting the interface defined by the abstract base class.
The Repository abstract base class defines a number of pure virtual member functions, which must be overridden by member functions with the same signatures in a derived class. The FileSystemRepository class derives from the Repository class, and overrides the pure virtual member functions to query the file system for photos. A shared instance of the FileSystemRepository class is then used by the view model classes to read photos from the file system. The following illustration shows this relationship:
Using this architecture also allows mock implementations of the repository to be created, to support unit testing. A mock implementation could be passed into the view model classes from unit tests, with the mock class simply returning mock photos rather than actual photos from the file system. For more information, see the Hilo project.
In the sample app, the ViewModelLocator class contains a member variable, m_repository, of type Repository, which is instantiated as a shared pointer of type FileSystemRepository in the class constructor. This instance is created as a shared pointer so that there’s only a single instance of the FileSystemRepository class in the app, which is then passed between the required classes.
ViewModelLocator::ViewModelLocator()
{ m_repository = std::make_shared<FileSystemRepository>();
}
The
ViewModelLocator class has properties that retrieve a view model object for each page of the app.
PhotoViewModel^ ViewModelLocator::PhotoVM::get()
{ return ref new PhotoViewModel(m_repository);
}
The
PhotoVM property creates a new instance of the
PhotoViewModel class, and passes in the shared pointer instance of the
FileSystemRepository class, to the
PhotoViewModel constructor. The shared pointer instance of the
FileSystemRepository class is then stored in the
m_repository member variable of the
PhotoViewModel class.
PhotoViewModel::PhotoViewModel(shared_ptr<Repository> repository) :
m_repository(repository)
{}
The
Image control in the
PhotoView class binds to the
Photo property of the
PhotoViewModel class. In turn, the
Photo property invokes the
GetPhotoAsync member function to retrieve the photo for display.
task<FileInformation^> PhotoViewModel::GetPhotoAsync()
{ return m_repository->GetPhotoAsync(m_path);
}
invokes
GetPhotoAsync on the shared pointer instance of the
FileSystemRepository class that is stored in the
m_repository member variable. The
Repository abstract base class defines two pure virtual member functions, including
GetPhotoAsync. The
FileSystemRepository class inherits from the
Repository class, and provides overridden implementations of the member functions. Here’s the code for the
GetPhotoAsync member function.
task<FileInformation^> FileSystemRepository::GetPhotoAsync(String^ path)
{ auto fileQuery = CreateFileQuery(KnownFolders::PicturesLibrary, path, IndexerOption::UseIndexerWhenAvailable);
auto fif = ref new FileInformationFactory(fileQuery, ThumbnailMode::PicturesView);
return create_task(fif->GetFilesAsync(0, 1)).then([](IVectorView<FileInformation^>^ files)
{ FileInformation^ file = nullptr;
auto size = files->Size;
if (size > 0)
{ file = files->GetAt(0);
}
return file;
}, task_continuation_context::use_current());
}
The
GetPhotoAsync member function calls an inline function,
CreateFileQuery, to create a file query that will be used by an instance of the
FileInformationFactory class to query the file system using
Advanced Query Syntax.
GetFilesAsync is then called on the
FileInformationFactory instance, which returns an
IVectorView collection of
FileInformation objects, representing each file found in the file system that matches the query. However, in this case the
IVectorView collection will only contain a maximum of one
FileInformation object, as
GetFilesAsync will only return one file that matches the query. The value-based continuation, which runs on the main thread, then gets the first file from the
IVectorView collection, before returning it to the
GetPhotoAsync member function in the
PhotoViewModel class, which in turn returns it to the
Photo property in that class, for display.
Summary
The repository pattern can be implemented in C++/CX by defining an abstract base class with pure virtual member functions. Subclasses of this class can then implement each of the virtual functions, which results in the subclass supporting the interface defined by the abstract base class. The main advantage of this approach is that a repository that accesses a data source, such as the file system, can easily be swapped out for a repository that access a different data source, such as the cloud.
