I am currently developing a Xamarin Forms app and am in the process of reworking it to work with Prism. I'm really trying to adhere to MVVM design patterns (I'm trying to grow as an amateur developer and learn how to use them).
1) Is it improper from a MVVM design pattern perspective to utilize messaging services (Prism's EventAggregator) and UI interactions (Prism's PageDialogService) outside of VMs? I've written several "services" that are called from the VM and have found a need to access both messaging and UI services. As one example, The VM calls a service, the service retrieves and processes some data, ask a question to the user based upon those calculations and then continue to finish processing returning the desired value. To be proper, should control be returned back to the VM to "just" ask the question?
2) If it's not verboten, is it possible to access the services outside of VMs? It does not readily appear to me that I can inject them into the constructor of the service. Is it okay to "pass" them into the service's function I'm calling along with other parameters? That just seems un... MVVM-ish?
Update:
I'm not sure all my steps were necessary, but with the help below I got it working. First I converted my singleton service into an interface (IMyService) and an implementing class (MyService). Next, I overrode ConfigureContainer in App.xaml.cs and called Container.RegisterType<IMyService, MyService>(new ContainerControlledLifetimeManager());
I could then inject IMyService, just like IEventAggregator and IPageDialogService into my ViewModels and I could also inject those services into the public constructor of my implementing class (MyService).
ad 1) the event aggregator is meant primarily for UI, but you can use it as message bus in other parts of the app, too, if you don't need the more advanced features of a "real" message bus.
ad 2) unity will happily inject dependencies into services that are themselves dependencies of view models or other services. That's what a dependency injection container does :-)
Related
Sorry, if it's kind of newb question. Please, help me to correctly name the architectures I described below.
Lets take we had web-application built with Spring framework/Hibernate/Thymeleaf(or another template engine) with the code of controllers looked like:
#Controller
public class AboutController {
#GetMapping("/about")
public String aboutview (Model model) {
return "about";
}
So, this is pure MVC software design pattern, as I take.
After this we switched from Thymeleaf to ReactJS for UI. So colleagues asked me to make few REST endpoints, which was used later for drawing single React's page. To be more concrete, let's take this controllers produced a filtered list of the users and goods, which was gotten from the JPA Repository.
So, the questions are:
To which architectural pattern did we switched off instead of pure MVC in above mentioned sample?
If it wasn't HMVC (hierarchical MVC), how it supposed to be looked like in term of controllers? Is it should look like few REST-controllers, which calls each other or simultaneously being called from React?
If I have few microservices, which has endpoints being called from the one React's page (or whatsoever JS framework), how can I correctly name an architecture of the Application: "microservice app with MVC pattern?"
Architecture of a software system is about what components exists in the system, how its components arranged. Of all the components, some of them will be in the same process communicating through function calls. Some of them will be in the same computer but running in different processes. (In this case, they will talk through OS provided inter-process communication). Finally, Some of them will be running in different computers of a network. (For instance; internet) [In this case, they will talk over a network through network protocols(for instance; http) using sockets]
Spring regular MVC or Spring REST Controllers are all about how the VIEW component and the component providing access to system functionality talk to each other and what computer VIEW and component providing access to system functionality runs in.
There might might be many more components which VIEW does not know about because of the fact that VIEW is isolated from other components through back-end API. (This is true for both classic MVC and REST controllers)
For instance; classic MVC or REST controllers might be run against a database or a file and that would not effect the VIEW. There might be a KAFKA broker and that would not effect the VIEW. (In terms of functionality).
When you write your back-end using REST API, mobile applications and other applications can consume that API. Classic MVC can only be consumed by a browser.
I'm building a WPF application using MVVM pattern, and Caliburn.Micro is the framework choice to boost up the development.
Different from a conventional MVVM-based application, I add a business layer (BL) below the ViewModel (VM) layer to handle logic for specific business cases. VM is left with data binding and simple conversion/presentation logic. Below BL is an extra Data Access layer (DAL) that encapsulates the Data model (DM) underneath built with Entity Framework.
I'm pretty new to both WPF, MVVM and, of course, know almost nothing about Caliburn. I have read plenty of questions and answers about the Caliburn usage and now trying to use what I've learnt so far in my application.
My questions are:
Does it sound okay with the above layered architecture?
In the application bootstrapper, is it correct that we can register all services that will later be used (like EventAgreggator (EA), WindowManager or extra security and validation services), and also all the concerned VMs? These should be injected into VM instances via constructors or so (supposed I'll be using SimpleContainer). So from any VM that are properly designed and instantiated, we can have these services ready to be used. If I understand correctly, Caliburn and its IoC maintain a kind of global state so that different VMs can use and share it.
Navigation: I know this topic has been discussed so many times. But just to be sure I'm doing the right way: There'd be a ShellViewModel acting as the main window for the whole application with different VMs (or screens) loaded dynamically. Each VM can inherit either Screen or ViewModelBase or NotifyChangedBase. When I'm in, let's say, VM A and want to switch to VM B. I'd from inside VM A send a message (using EA) to the ShellViewModel, saying that I want to change to B. ShellViewModel receives the message and reloads its CurrentViewModel property. What should be a proper data structure to maintain the list of VMs to be loaded? How can stuffs like Conductor or WindowManger come into the place?
Can/Should Caliburn in one way or another support the access to the database (via EF). Or this access should be exposed to VM and/or BL only?
Thanks a lot!
Different from a conventional MVVM-based application, I add a business layer (BL) below the ViewModel (VM) layer
That's the standard case. ViewModels can't/shouldn't contain business logic which is considered to be part of the Model (Model in MVVM is considered a layer, not an object or data structure) in the MVVM. ViewModel is for presentation logic only.
Yes, as long as your Business (Domain) Layer has no dependency on the DAL (no reference to it's assembly). Repository interfaces should be defined in the Business Layer, their implementations in the Data Access Layer.
Yes, Bootstrapper is where you build your object graph (configuration the IoC container).
Registering ViewModels: Depends on IoC framework. Some frameworks let you resolve unregistered types, as long as they are not abstract or interfaces (i.e. Unity). Not sure about Caliburn, haven't used it. If the IoC supports it, you don't need to register them.
One possible way to do it. I prefer navigation services though, works better for passing around parameters to views and windows that are not yet instantiated and you always know there is exactly one objects handling it.
With messages, there could be 0, 1 or many objects listening to it. Up to you
What do you mean with support access to the database? You can use it to inject your repositories and/or services into your ViewModels, other than that there isn't much DB related stuff to it.
Instead of using flux/redux architecture, how react components should communicate with services?
For example:
There is a container having few representational (react) components:
ChatBox - enables to read/write messages
AvatarBox with password changer - which enables to change user's password
News stream - lists news and apply filter to them
Thinking of them as resources representation, I want each of them to access Microservice API by itself (getting or updating data). Is this correct?
It will provide clean responsibility managing models, but it gives performance doubts using http requests to load each component's content
This question also reffers to: How to execute efficient communication for multiple (micro)services?
When you opt for not using Flux/Redux, here is what you do:
Create an outer component that should wrap all the other components. This component is also known as a higher order component or a controller view. This component should use an HTTP library to communicate with your microservices (I personally like Axios). I would recommend that you create a client API object that wraps Axios. Your higher order component can reference this client API so it is agnostic of the HTTP library and whatnots. I would also put a reference of this client API on the window object in dev mode so you can do window.clientApi.fetchSomething() in the Chrome console and make debugging easier.
Make all the other components (ChatBox, AvatarBox and NewsStream) controlled. If you are not familiar with this concept, it means they receive everything they need through props and they avoid keeping state. These components should not call the microservices themselves. This is responsability of the higher order component. In order to be interactive, these components should receive event handlers as functions as props.
Is this correct? It will provide clean responsibility managing models, but it gives performance doubts using http requests to load each component's content
You can avoid performance issues by not allowing each component to directly contact the microservices. If your higher order component compiles all the information needed and make as little as possible HTTP calls, you should be perfectly fine with this approach.
It's generally recommended to use Flux/Redux, but if you opt out, this is how to go about it.
According to: https://facebook.github.io/flux/docs/overview.html#content
Occasionally we may need to add additional controller-views deeper in the
hierarchy to keep components simple. This might help us to better encapsulate a
section of the hierarchy related to a specific data domain.
And this is what I am thinking about responsibility of particulary component's domain (three of them was described). So could it be reliable to make three controller views (or stores) that can access dependent API to manage resource's data?
Is it appropriate to expose a ReactiveCollection in an API? Specifically, in a service class that would be used internally on multiple applications. But as a thought experiment, we can also consider in public use as well.
I've been investigating Rx and ReactiveUI, and these seem like powerful tools. However, I don't have enough experience with them to determine if it is a good idea to require others to take a dependency on them.
More details:
I'm creating a tracking service class that would track connected clients. From my view, all that would be necessary for consumers to use this class is to expose an observable collection (possibly a ReactiveCollection) that exposes the connected clients, and notifies of changes to the collection which are managed by the service. The entitity representing the connected clients would also take advantage of INotifyPropertyChanged to notify of updates to the clients' state.
Since ReactiveCollection is a derivative of .NET's ObservableCollection (i.e. the non-Rx WPF/SL one), you could expose it as an ObservableCollection instead.
I'm new to MVVM. Currently I'm developing a WPF project in C# that will have a SQl Server backend and I'll be using a standard WCF service to communicate with it. All the tutorials I've seen on MVVM thus far always seem to use some static data repository such as an xml file for their backend. I haven't yet seen implemenations using a database and a data access layer, so I'm confused as to where my WCF service fits in. The service has all data objects defined in it, so does the service itself then become the model? In addition, how do I go about including the service in the ViewModel so that the designer doesn't throw an error stating that it cannot create an instance f the service class? Any help here would be greatly appreciated as I find it strange that so many tutorials on this subject omit the most prctical implementation for a line-of-business application.
PS I would like to steer clear of WCF RIA services and Silverlight as the Silverlight's lack of support for commands makes the book I'm following (Pro WPF and Silverlight MVVM Effective Application Development with Model-View-ViewModel) difficult to understand.
OK, I'll try to get you up to speed ...
First, I do recognize the question about the model and the object model exposed with WCF. Are they the same? Well, I would like to make that assumption currently, for sake of simplicity. So then we do not need the model part of MVVM on the client side? Depends ...
The ViewModel is in the driving seat. We let it create the client proxy to your WCF service. The objects used in the request and returned as result makes your model. Anything you want to cache on the client side or is not directly bindable with the UI will be put in properties in your model container class. Generate bindable properties from these model properties for consumption in your UI. Every else will just be direct properties in your view model.
About WCF and the data access layer, there are a few important thing to recognize. First of all, you will need to have a seperation between you logical (information) model and your physical (database) model. One reason is to abstract your database technology away from your application. Another to allow small deviations between your application / domain logic and your physical implementation. Make sure your (entity) model classes are generic enough to support changes in your UI without having to modify the complete application stack for every UI change.
It is hard to talk about this matter without a clear example, so to wrap up I would like to invite you to look at http://aviadezra.blogspot.com/2010/10/silverlight-mvvm-odata-wcf-data.html. I know, it IS using WCF data services and SilverLight. Don't be mad at me directly for directing to this sample and give me the thumb down. It is just such a damn good example of what you want to achieve and what to introduce and what to think about setting up such an application. Just replace Silverlight by WPF and Data Services by regular typed data contracts and the rest of the story will help to get your thoughts clear.
Hope it helps you in your quest!