Tag Info

Hot answers tagged

14

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 ...


13

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. ...


13

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 ...


12

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 ...


11

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 ...


10

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 ...


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

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 ...


9

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 ...


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

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 ...


8

I have worked on multiple large, enterprise-scale projects and MVVM was the KEY to keeping them scalable and maintianable. I can't imagine having separate design and development teams being able to work in true parallel without the workflow enabled by the pattern, nor would we have been able to have the team split between tiers, i.e. having someone code the ...


8

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).


8

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 ...


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

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 ...


7

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 ...


6

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 ...


6

The XAML and the code behind together represent the view, i.e. the visual representation of the ViewModel. A lot of the time the tools and methods available in XAML (i.e. data-binding declarations with formatters and whatever templates you need) are sufficient to control the layout to your satisfaction, and so the code behind is not needed or can be empty. ...


6

MVVM isn't outdated, but it was overplayed to begin with. I never liked it and it kept me in WinForms for too long; failing to see the forest for the trees, I threw the baby out with the bathwater. I get WPF now, and I get the idea of not wanting to mix code with markup, but I prefer the Android style of sticking the markup in one place and dereferencing ...


6

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 ...


6

Your phrase "Is the coordinator and translator between the Model and the View." indicates that your Bridge is the Presenter in an MVP architecture. MVP and MVC are very similar, except that in MVP only the Presenter observes the Model while in MVC the View is also allowed to directly observe the Model (without the Presenter as a "Bridge"). ...


5

The only advice I can give is that the exception and overall error handling should be taken care at the design level, and not at the implementation level. Making sure that at least a proper framework is at place for error-handling is important. Adding exception code later, most probably will need the design change and hence many changes in the code than ...


5

The question you need to ask is "why is this widget being hidden?" If the answer is because it's not available, your VM property should probably be a bool called IsAvailable. If it's because some other property has or doesn't have a particular value, do it with an IValueConverter. The general concept is that the VM holds the conceptual state of the system, ...


5

MVVM outside of the Microsoft is known by another name. Presentation Model. This appears to be gaining traction especially in the Flex world. I'm still learning the ropes but it seems to be gaining traction. Various Flex examples I have found recently are: Cafe Townsend Score Keeper One question that continues to bug me is when do you need a dedicated ...


5

MVVM is a UI pattern and is used in a client. The parts of the domain in DDD that are used in the client are probably (a part of) the Model The View and ViewModel are client only. I put Repositories in (or near) the Model because they synchronize the Model to the back-end. Yes, many times this will result in multiple Person classes in different ...


5

Personally I see nothing wrong with binding directly to the Model instead of exposing properties through the ViewModel, however if you plan on binding to your EF POCO classes, you need to have them implement INotifyPropertyChanged so the UI knows when they update. EF should have a setting that will make it generate the classes with INotifyPropertyChanged ...


5

Not MVVM: ViewModel isn't acting as an interface between model and View. ViewModel doesn't provide data binding between View and model data. ViewModel doesn't handle all UI actions by using command. State and logic aren't stored in the Presenter. View isn't isolated from the Model. View isn't aware of the Presenter. If your projet has at least one of the ...


5

The command should be on the ViewModel. In MVVM, the ViewModel is the thing that should contain all of the logic that drives the view. The view is the simple class - just a collection of UI controls whose state is bound to properties on the ViewModel. Josh Smith wrote a really good intro to MVVM that should clear things up for you.


5

Practice, practice, practice. Also, don't assume you know the language. The fact that you're surprised to see someone register and unregister events shows that you have still things to learn about the language. The fact that you're surprised to see Actions in action indicates that you also have things to learn in .NET Framework. Is it normal? Totally. ...



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