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 ...
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.
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 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
While working on a LOB desktop application with a lot of CRUD operations using PRISM and Enterprise Library, I have noticed a recurring pattern that seems annoying. For every domain model entity (eg. Contact) I find my self wrapping it with a view model (eg. ContactVM) then I introduce a new ContactsVM (notice the 's') where the latter class accepts a repository interface which is used to populate an ObservableCollection<ContactVM> and for every Contact entity that I read from the repository, I wrap it in a ContactVM which I pass the entity to via the constructor along with other enterprise library services needed by my ViewModel.
The problem is that all my view model constructors started taking this pattern like this:
ViewModel(EntityToWrap e, DependencyFromEntLib, OtherDependencies ...)
Now that is a problem because most tools and libraries require a default parameterless constructor (eg. some commercial data grids need that to provide filtering support), plus you can't use design data to visualize entities because they need parameterless constructors too. and finally the question: What is the right way to build view models and should Entlib services be provided via constructors or via the ServiceLocator ?
The following is one of many different ways to approach the problem.
I prefer view models which are much more lightweight. I then add a class whose responsibility is to compose the view model from one or more sources (e.g. a repository). This doesn't eliminate the problem of cascading dependencies, but it does free up your view model constructors.
It also keeps logic out of the controllers, and allows view models to be reused (when appropriate, of course).
Lightweight view models
Lightweight controller knows how to locate a composer which assembles the view model (you could use a DI framework to setup the composer with all of its dependencies). The controller may play a minor role in the setup process, but it should be kept simple.
Controller knows how the view model should be assembled, and shares that with the composer class. For example, the action might request a summary view which can still leverage the same view model with no children populated.
Composer assembles the necessary information to complete the view model. Composer may use other composers to gather information for which it is not directly responsible. Again, a DI framework can be used here so that these composers are also given the dependencies that they need.
Controller renders the view as usual with the completed view model.
In my opinion, this also provides a better level of abstraction. Just because a view model often looks like a particular domain model, that doesn't mean it will always be the case.
The end result:
Lots of classes (a downside, granted), but minimal repetition of code (i.e. DRY)
Thin view models which are testable (if needed...they may contain nothing to test)
Thin, testable controllers.
Testable composer objects which can be reused for different scenarios because they (presumably) know how to assemble view model(s) for various purposes.
Flexibility to mix and match view models, controllers, and composers to support different scenarios.
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.