Hot answers tagged

25

I think a lot of programmers first try to take the shortcut of binding directly to the model, but in my experience this has some major drawbacks. The primary problem is that if your entity model is persisted by NHibernate or similar, then as soon as the View updates the model property, then NHibernate could persist those changes to the database. That doesn'...


21

Navigation should always be handled in the ViewModel. You're on the right track with thinking that the perfect implementation of the MVVM design pattern would mean you could run your application entirely without Views, and you can't do that if your Views control your Navigation. I usually have an ApplicationViewModel, or ShellViewModel, which handles the ...


19

MVVM is intended to be used where complex user interactions using high-fidelity UI's are needed (i.e. WPF). MVVM is targeted at modern UI development platforms (Windows Presentation Foundation, or WPF, and Silverlight) in which there is a user experience (UXi) developer who has requirements different from those of a more “traditional” developer (e.g. ...


19

In fact, both of these solutions are bad. Creating a services singleton (IServices) containing all the available services as interfaces. Example: Services.Current.XXXService.Retrieve(), Services.Current.YYYService.Retrieve(). That way, I don't have a huge constructor with a ton of services parameters in them. This is essentially the Service Locator ...


18

In general, I would not place business logic in the view model layer. But the term "Business Logic" is misleading. Eric Evans uses a model where business logic is divided into two categories Domain logic - Logic related to the actual problem domain you are solving Application logic - Logic related to the fact, that you are building an application He ...


17

Is this the same thing as the 'ViewModel' from the Model-View-ViewModel (MVVM) design pattern Nope. That would be this: That has cycles. Uncle Bob has been carefully avoiding cycles. Instead you have this: Which certainly doesn't have cycles. But its leaving you wondering how the view knows about an update. We'll get to that in a moment. or is it a ...


16

The point of a ViewModel is that it is a model of the View. You should be binding the ViewModel to the View, not any Model properties (not directly, anyways).


15

Sometimes MVVM can be a trap. From my experience it favors CRUD-like applications (forms over data) versus more task-oriented UIs. I'm not saying that it implies bad architecture for the back end/others layers in the application but I have seen a lot MVVM applications coming with "DDD light" architecture. I don't know why exactly maybe because the binding is ...


15

You know when you are violating MVVM when: The ViewModel is aware of the View. The ViewModel should never know or care if or what is sitting on top of it. It simply is. Sometimes, the ViewModel might need to generate events that should be handled on the View. When I was working with MVVM, we used the Mediator pattern to handle those cases. The Model is ...


15

I have tried CaliburnMicro and MVVMLight and when using Caliburn I really feel what you feel, sure it feel really magical able to bind control to property just by using Name="PropertyName" instead of old Text="{Bind PropertyName}" but in the end Caliburn goes way overboard to do this magical thing, when something goes wrong it really hard to debug, to make ...


13

MVVM is a band-aid for poorly designed data binding layers. In particular, it has seen a lot of use in the WPF/silverlight/WP7 world because of limitations in data binding in WPF/XAML. From now on, I'm going to assume we're talking about WPF/XAML since this will make things more clear. Lets look at some of the shortcomings that MVVM sets out to solve in WPF/...


12

It looks like you've found yourself in perfect learning situation. Currently your application works, and I'm sure you're very familiar with all of the 20k lines of code. Making changes isn't that difficult, and, so far, there doesn't seem to be any reason to change your development approach. You are a cowboy! And being a cowboy is a lot of fun! But ...


11

MVVM is (yet another) variation on patterns that separate the concerns of a typical presentation, much like MVC and MVP. Regardless of these variations, the basic concerns are the following triad: the Model (the underlying data and domain objects). the View (what the user actually sees and interacts with) the facade that translates between the Model and ...


10

Is there any easy step-by-step reference to MVVM? Yes, there is. Take a look at the here. Is MVVM a super-set or a sub-set of MVC? MVVM belongs to the MVC family, so, if you can say that at all, it's a subset. It's a variant to decouple the UI from the business logic underneath. I'd describe it as a sibling of MVC. Since the early days of OOP people ...


10

I have used ValueConverters in some cases and put the logic in the ViewModel in others. My feeling is that a ValueConverter becomes part of the View layer, so if the logic is really part of the View then put it there, otherwise put it in the ViewModel. Personally I don't see a problem with a ViewModel dealing with View-specific concepts like Brushes ...


10

To answer the question, Yes, each view should have its own View Model. But there is no need to model the entire hierarchy. Only what the view needs. The problem I had with most online resources regarding MVVM: In most examples, the View is almost 1-to-1 mapping of the Model. But in my scenario, where there are different views for different facets of the ...


10

First off, take a look at the basics of MVVM to get a better understanding of how the pattern is supposed to work. This WPF specific version may be of interest as well. Generally speaking, the pattern looks like this: View <= (bound) => ViewModel <= (function calls + async callbacks) => Model With that diagram in mind, it should be a little more ...


10

It is important to realize what MVVM is. It is not some shared bit of functionality that you do not have to reimplement (parsing a JPEG file or connecting to a given SQL database server), it is a pattern--a pattern for how one may choose to implement a rich GUI. So, if your implementation of the pattern is simple and straightforward, I do not think you need ...


9

Well, I want to be in the know too - because being out of the know makes me feel insecure and a little sad. +1 for being able to express yourself without shame. I would suggest following blogs. If you want to be "in the know", then follow these people General cool stuff: Rob Conery; Jeff Atwood, Joel Spolsky MVC: Scott Hanselmann, Rachel Appel, Rob ...


9

My perspective is from years of experience working with Winforms, the "old fashioned way," with events and code-behind. So I can tell you with absolute certainty that, once you get beyond the simplest of applications, your code quickly becomes a big ball of mud. It was inevitable, because that's the way applications were written back then. Webforms is just ...


9

The thing is - if you write clean and modular code in a complex applications (I mean application with lots of UI functionality, since the question was particulary about JS and MV* frameworks), you will realize, eventually, that you are doing an application in MV* style. It could have another implementation and code look, but it will be MV*-application. I ...


8

I really like MVVM and I find its challenges motivating and see the many benefits, but... For application or games that require a lot of UI/interaction code to add a lot of custom behaviors while keeping perf up - it is often better to use a bit dirty MVVM - use it when it is useful or in more data centric as opposed to interaction centric areas of the code....


8

I've been a WPF/Silverlight programmer for years building huge applications, such as trading systems, on MVVM. For me, as the years have gone by, I've learned that strict MVVM eats time and costs money. By strict, I mean rules such as "no code behind". It's impossible in anything but the most basic form/database app, not to have code-behind. Your designer ...


8

I find both methods acceptable Binding only to the ViewModel is the "MVVM-purist" approach and leads to better separation between layers. Binding to the Model is usually faster and more convenient. Unless I have a good reason to fully separate the layers (size of project, future maintenance concerns, type of Model I'm working with, etc), I bind to the ...


8

You should look into Spring4D as it already contains nullable types (similar implementation as yours with a little extra operator overloading) and way more powerful collection types than those in the RTL. They are also interfaced based which is very handy because you don't have to worry about lifetime management especially when passing them around. For ...


8

Those are different non-competing concepts and they can easily work together to produce a great result. In layman terms: MVVM is useful to get away from the codebehind (GUI/model coupling) clutter. Reactive approach is useful to reduce the event/callback clutter. I would recommend learning a bit about XAML/WPF since Microsoft is the original inventor of ...


8

I use dependency injection and a IViewFactory injected into the view model to respect both constraints. A ProductViewModel (for example) calls this.viewFactory.Show("Details", this) to open ProductDetailsView with itself as ProductViewModel. It could also open a view based on another view model with this.viewFactory.Show<ClientViewModel>(). The ...


7

If your application requires that you bind to excessive amounts of data in real time, then MVVM can actually get in the way because it's introducing abstractions that slow the process down and, assuming we are talking about WPF/Silverlight/WP7 right now, the binding engine is currently not that efficient; although enhancements are on the way. MVVM, as it ...


7

If the View-Model is only concerned with a control being visible or collapsed, then I'd make it a boolean and use a value converter. If the View-Model also needs to communicate the hidden state, then I'd make it an enum (and probably use the Visibility enum). So to answer your question, I'd have the View-Model express what it needs (visible/collapsed or ...


7

If the Conversion is something View-Related, such as deciding the visibility of an object, determining which image to display, or figuring out what brush color to use, I always put my converters in the View. If its Business-Related, such as determining if a field should be masked, or if a user has permission to perform an action, then the conversion happens ...


Only top voted, non community-wiki answers of a minimum length are eligible