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


22

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


19

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

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


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


13

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


13

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


10

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


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

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


9

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


9

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

The View is the place which has intimate knowledge of your graphical runtime environment, of how color is expressed in it, and even of the fact that you are actually running within a graphical runtime environment and not as part of some unit test. (Assuming that you unit-test your Model, and your View Model, but not your View.) So, I would think that the ...


8

I think I know what you mean. Basically you solve the problem by adding either a 'controller' or a 'master' viewmodel (excuse psudocode) ie public class MasterVM { public ChildVM View1 {get;set;} public ChildVM View2 {get;set;} private Data data; public MasterVM() { View1.OnEvent += updateData; } private Action<int&...


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

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


7

You're definitely on the right track in making a Data Access Layer, although I would suggest making it more like a mysterious black box whose inner workings are unknown. What I mean by this is your objects should be able to use the DAL to get/save objects, but they should have no idea how the data is actually obtained. For example, instead of your ...


7

I think what you are seeing is a concept called bind through, that is if your model has a property called name and your view-model exposes this property with no additional editing or converting then you can bind through to the model so it would be. Pseudo Code: {Binding: MyViewModel.MyModel.Name} This is done to reduce the amount of 'Fluff' properties on ...


7

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


7

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.


7

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


7

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


7

My first experience with WPF has been using Caliburn.Micro so this is probably quite different from most developers. I have found both WPF and Caliburn.Micro to be quite a steep learning curve, coming from WinForms, however after some experience with both I have found them a pleasure to use as a pair. Currently working in a different organization where ...


7

This may not answer everything you are asking, but it's too much for a comment. Your solution's organization (I use the term organization rather than architecture) should reflect how you use it. It should be efficient for your use. For instance, when you want to make a change to a Menu does a developer have to open files from View/Menus and also from ...


7

Theoretical answer If you have a ViewModel, actions that have cosmetic effects (e.g. highlight an item on mouseover) are the job of the View, while actions that have "real" effects (e.g. spawning a new window) are the job of the ViewModel. As such, creating a new window is a job for the ViewModel. However, neither the View nor the ViewModel should know ...


6

For the sake of closure, I thought I would post the direction I finally chose to solve this problem. The first decision was to leverage the Silverlight Page Navigation framework provided out-of-the-box. This decision was based on a several factors including knowledge that this type of navigation is being carried forward by Microsoft into Windows 8 Metro ...


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