I have developed a WPF-application. I have a mainwindow which inherit from Window, a tabcontrol and many tabitems in this tabcontrol which inherit from UserControl. Every tabitem has its own cs-file, where I code in C# all the businesslogic, and a XAML-file where the development of the UI is done. I also have a SQL Server with a database which i connect to trough LINQ.
So i have to write about my choice of which controller i use in my application. This is where i get confused, since i havent manually programmed a controller and i thought the ViewModel would behave like a controller in my case. Could this be correct? Can the ViewModel behave like a controller?
A controller can send commands to its associated view to change the view's presentation of the model (e.g., by scrolling through a document). It can also send commands to the model to update the model's state (e.g., editing a document). Model_View_Controller
The viewmodel is a “model of the view” meaning it is an abstraction of the view that also serves in mediating between the view and the model which is the target of the view data bindings. It could be seen as a specialized aspect of what would be a controller (in the MVC pattern) that acts as a converter that changes model information into view information and passes commands from the view into the model. The view model exposes public properties, commands, and abstractions. Model_View_ViewModel
The introduction of MVVMC (MVC + MVVM) is nessesary in cases you would like to drive many similar pairs of View-ViewModel (use cases). You can then introduce controllers. Model_View_ViewModel_Controller
In the simplest case, have the ViewModel implement the "controller" logic. For large applications, I sometimes use an MVVMC pattern which uses a separate controller class. There has been a lot of recent support on the blogosphere for using MVVMC over MVVM.
MVVM is dead, long live MVVMC!
MVMMC – MVVM grows a Controller
Related
I have a C# Application with two different views. Each view has an own ViewModel. The ViewModels access the same Model. The Views need the data from the same Model in a different format. The ViewModels handle the formatting and validation.
Both ViewModels should be able to communicate with each other in some way. For example if ViewModel1 updates something in the Model ViewModel2 should also update his View. The ViewModels don't have to know each other, they should just get synced when one side changes something.
I found some old posts aout the Mediator pattern. Is this still the way to go? I think the Observer pattern would not work here. The only alternative I could think of was to create a Interface on both ViewModels which let them talk to each other.
i think what your looking for is Message-passing system for your View Models.if you what them to be loosely coupled you can use events to implement one by yourself.
also there is Event Aggregator class in prism library that do the same.some classes subscribe and some publish their messages.
The pattern most relevant to this would be MVC. If you are using .Net Core, you can read up on it on the Microsoft Docs online.
The Controller would be able to return a View Model that has the updated values. You could also have just 1 View model that is used by both views that you have.
I have inherited some code for a fairly complex WPF application which uses Caliburn.Micro to implementt the MVVM pattern. It uses views bound automatically to view models using the Caliburn naming conventions. The view models inherit from a class that implements INotifyDataErrorInfo, and Fluent Validation is used to generate field-specific errors. This works perfectly, except in one scenario where I have a user control embedded into several different views, and the UI elements within that user control need to be validated.
The embedded user control has it's own view model, which doesn't implement INotifyDataErrorInfo. Suffice to say that the validation messages we generate when validating the parent view do not propagate up to the UI for display.
I'm not quite sure what code I would need to show here to illustrate the problem, so the question is more conceptual really - the question is:
Im my scenario, should I be implementing on the view model behind the embedded user control, or is there some other way to make the parent view call GetErrors() on it's view model with the property names of controls nested within embedded user controls?
I hope that makes sense - I'm quite new to WPF!
I ended up solving this. The problem turned out to be that I had a separate view model bound to the nested view, and that view model did not inherit from a class that implemented INotifyDataErrorInfo. Suffice to say that the rule here seems to be you can have embedded user controls which have their own view model (datacontext) and still get the validation behaviour, but every view model in the hierarchy must implementINotifyDataErrorInfo otherwise the UI elements bound to them won't get notified of errors. In my case it was difficult to see problem because Caliburn.Micro and AutoFac were doing a lot of auto-wiring that was hard to see in a debug context.
So I was first introduced to the idea of a model when I learned WPF. The MVVM concept of a model seems to be more aligned to general 'business logic' encased in a class/set of classes. When I look at MVC though, the model seems to be lightweight-classes that are "passed" to and from the user via forms. Is this assessment correct, or are there situations where a model is something heavier (does more than just hold and validate data input from the user).
You can use Models (classes) as data container (which i usually do) , look at anemic domain model (http://en.wikipedia.org/wiki/Anemic_domain_model), then you can implement business layer, service, data layer independently.
Or you can implement them within your model, which some folks wants to do that due to encapsulation, and several design priciples.
Look into domain driven design as well. (http://en.wikipedia.org/wiki/Domain-driven_design)
Well in MVC or another similar Design Pattern you have defined 3 separate layers of your application. The model with the logic of your objects, the view for showing and getting information from the user, and then a controller witch does the interaction and exchanges between the 2.
MVC is more used for web apps and MVVM with WPF. The reason is that you with WPF can do the databinding of the objects in your View with the one in the ViewModel.
For example a Twiter app: You can do have a model (tweetItem) with all the properties of a Tweet, a ViewModel that gets and stores the tweets in an collection and view that has a list, for showing them, binded to that collection.
There for MVVM or MVC only impact in your app is on how the code is organized.
I have a WPF application that looks something like this:
The viewmodel wraps the model and exposes any attributes relevant to the view via INotifyChanged. The view is also bound to several ICommand objects that handle certain behavior triggered by the view. I have an external ICommand who's sole purpose is to save the model to a database.
Everything I've read indicates that neither the view or the viewmodel should have a reference to the repository. This is the reason for Command 3 which is outside of the viewmodel.
My question is twofold. First, is this a reasonable architecture, and second, what is a good way to get the model instance over to command 3 so it can be put in the repository?
I, personally, see no problem with having the ViewModel have a reference to the repository. Trying to avoid this will cause unnecessary complications.
In MVVM, the ViewModel is typically the "glue" layer that sits above your Model - and the Repository is part of the Model (it's part of the domain specific data/logic). My blog series on MVVM shows a good image of how I personally think about this:
Letting the VM work with the Repository directly by putting Command 3 into the VM would likely be cleaner than trying to separate it out.
The View Model should communicate to the Business Layer (Domain Objects + Domain Services) and not the repository directly. Even further, this communication should be done via Commands.
So you have:
View -> View Model -> Command -> Domain Object / Domain Service -> Repository
Unless you are developing a really simple CRUD application ...
I have viewmodel1 and viewmodel2.
Viewmodel1 needs to show data from a list of some sort contained in model.
Viewmodel2 needs to input data to the list contained in model.
So both Viewmodel1 and Viewmodel2 need to "know" about model.
What is the proper way to do this in MVVM?
Should I create model in app and give viewmodel1 and viewmodel2 a reference to it or?
I find it helps if I think of a ViewModel as being a Model, translated just for the View.
You have a few choices:
Create a controller which sets up the ViewModel. This is usually a good choice if the ViewModel needs information from more than one place. You can either give the ViewModel a reference to all the information it needs, or make it a Plain Old .NET Object (PONO) and have the controller set it up for you.
Just pass the reference to the ViewModel as you suggest. Useful if no interaction is required between different classes
Wire up the EventAggregator, which can be used to publish a notification when models change, and pass a Repository to the ViewModels so that each of them can go and get / store the model when they need to.
I really like the last pattern as it's easily scalable if you find you need more presenters or controllers with access to these kinds of models. It also lets you inject a repository, which means you can more easily move to a nice RESTful service-oriented architecture later.
If you haven't done much dependency injection before then please consider doing it through the constructor. This will help you avoid situations where things are trying to use your ViewModels before they're ready, and lets the ViewModels do their own work. You might also want to look at frameworks like Unity or Castle Windsor which can help you do this kind of wiring, but that's really only for big Enterprise projects (and not even all of them).
That's perfectly fine. Models are meant to be just what they sound like: data models. They're meant to be dummy objects that hold data, which the rest of the application can use as needed.
ViewModels are models that reflect the View. For example, suppose you had a LoginViewModel and an ManageUsersViewModel. Both ViewModels would work with the UserModel data object, however they are entirely different ViewModels for entirely different things.
In most cases, I would leave the responsibility of loading Models up to the ViewModel. For example, you normally wouldn't pre-load the Users list prior to the User logging in so you'd have their User object available. Insetad, your LoginViewModel would make it's own database call to get the User model of the user logging in, while the ManagerUsersViewModel would make its own database call to get the list of users that can be modified.
You must be thinking in a wrong way.. in MVVM your model are contained in ViewModels all the way to the views.. lets say if there is a ObservableCollection then there will be a property in you viewmodel for this and you should be initializing this collection in constructor/some method of the ViewModel.. both viewmodels will initialize ProductTypes like this.. In my opinion you should try create Classed For Model,ViewModel,Repository and use IoC in it..
here is a really good video on mvvm you should try this video and have a look at the code as well.
http://blog.lab49.com/archives/2650
If the List you mentioned is something that will never change you should try creating a singleton ViewModel for this and reference that viewmodel in other viewmodels.
Regards.