I'm in some sort of confusion: at one hand Microsoft architects and surrounding web community promote MVVM pattern for building WPF apps, but from the other hand in Prism patterns and practices they uses absolutely other design patterns - MVP, Presentation Model and Supervising Controller! And not a single example of use pure MVVM! They even say nothing about using MVVM in their PRISM documentation! So, what should one do in this situation? Is it possible to use MVVM pattern in PRISM applications with the same level of freedom as with patterns listed above? I mean would it be more complex or not because of (probably) kind a native architectural optimization for these patterns?
Absolutely. PRISM glues the parts of your composite application together, but those parts may use MVVM or whatever pattern you prefer (as can your Shell).
You can definitely use MVVM with Prism.
Blaine Wastell from the Patterns and Practices group has said that the next version of Prism (v4) will contain more help for the MVVM pattern. I've read somewhere else that this means better support for MVVM in Blend, and more MVVM in the documentation.
http://blogs.msdn.com/blaine/archive/2010/01/15/prism-4-0.aspx
Related
While creating app in Xamarin Forms using Mvvm and MvvmLight, couldn't find significant reason of using MvvmLight. As all the features are already being provided by the xamarin forms/.net.
So if someone could point out the significance of MvvmLight (maybe with an example)?
This is probably just what people are used to using with WPF. Instead of re-learning the terminology of Xamarin.Forms Mvvm they stick with Mvvmlight.
There are probably other reasons. Mvvmlight focus solely on Mvvm where as Xamarin.Forms resources are more spread out so may not adapt to design pattern changes as quickly as MvvmLight.
If I were choosing an Mvvm library to use I would choose MvvmLight for the reasons stated above
I have been using MVVM light for some time, the one thing I love is that You can make UI changes to datatemplates during design time.
I am still new to Xamarin MVVM, but from what I can tell you have no design time preview in the shared project(Xamarin Forms) yet.
So MVVM light may not give you such an advantage.
Questions to ask yourself is why you would need an MVVM library in the first place.
I've done some research about this topic and i already used the MVVM pattern in few applications.
I'm asking this question because sometimes MVVM is referred as a design and sometimes as an architectural pattern.
In most of the cases, the MVVM Pattern is called a design pattern. However personally I would vote for architectural because for me it clearly defines the architecture of an application (eg. three layer, View, ViewModel, Model and how they interact with each other)
This SO Question & Answer is about the difference between architectural and design pattern. In the answer it is said that MVC is a architectural pattern. Almost every explanation of MVVM contains a comparison with MVC. Is MVVM therefore also an architectural pattern?
This msdn article (which is btw very good) calls the MVVM Pattern a design pattern and is written by someone who really should know the difference.
I'm confused. Design or architectural pattern? is the term just mixed up?
EDIT: i need to know this for my bachelor thesis
I tend to think of architectural patterns as "decisions" with a lasting ramifications. They make up the skeleton of your application and so it is hard to get away from them.
For instance, a methodology for how to build your views is very hard to get away from, so I'd call it an architectural pattern. Microsoft designed ASP.NET WebForms to work a lot like WinForms. It was difficult to switch to a more MVVM approach mid-way through a project. Even choosing WebForms as your technology stack drastically affected what you could do with your application.
I think of design patterns as variants of an implementation - they can be used without impacting the rest of the application. You typically refactor to patterns, with the expectation that the code will change. To the point, design patterns are meant to help facilitate future change.
Obviously there is a fuzzy line between the two. Consider the repository pattern (typically considered an architectural pattern). It is really a facade (or proxy) to your data tier. Here, you pointing out a recurring use of a design pattern - elevating it to an architectural pattern - because it affects how you architect your system. You now have a rule: whenever I hit the database, I will do this, this and this.
MVVM is the UI-related design pattern as per Microsoft. check below link
wpf-apps-with-the-model-view-viewmodel-design-pattern
Architectural patterns are at higher level than design patterns. Architectural patterns are high-level strategies that concerns large-scale components, the global properties and mechanisms of a system.
Or in more simplified term, Architectural pattern define the components involved in the system on a higher level, how are they assembled and organised, and how they communicate with each other.
Design patterns are usually associated with code level commonalities or can say it is on lower level which explains how the software/component is built.
Holistically :
Architectural patterns - fundamental structural organization for software systems **(Deals with separation of concern)
Design patterns - Deals with implementation level details in software/software component construction
I am thinking about developing a new application using web toolkit. I decided that the best option is going to be to use the Model-View-Presenter Design Pattern. After doing plenty of research, I found two different ways of implementing the skeleton code. (I am still trying to learn MVP and how to best utilize the disjunction between the model and the view)
Here are the two links discussing GWT MVP
https://developers.google.com/web-toolkit/doc/latest/DevGuideMvpActivitiesAndPlaces
https://developers.google.com/web-toolkit/articles/mvp-architecture
I read through and understand all the information in the second link, how you associate presenters with views, and how you have your custom events and such. I really like this because this means that several developers will be able to work on the project I have in mind.
However, the first link, also points out some interesting stuff, mostly using XML and #UiBinder and other things. I feel that those will not be necessary for this particular application but I want to make sure I have not overlooked anything.
Basically - How good of a programming practice is the style the style in the second link (the one with presenters for each view)
Thank you
You should be not be comparing MVPActivitiesAndPlaces and MVP . If browser history management is not your concern use only MVP.
Activities And Places are not mandatory for MVP. They only allow you clean browser history management which integrates nicely with MVP architecture.
UiBinder is not mandatory for MVP. They can be used with MVP.
The MVP design paradigm mostly is driven with Unit testing as main driver and to keep out slow running GWTTestCase out as much as possible.
At the heart of this pattern is the separation of functionality into
components that logically make sense, but in the case of GWT there is
a clear focus on making the view as simple as possible in order to
minimize our reliance on GWTTestCase and reduce the overall time spent
running tests.
Is it possible to adopt MVVM design pattern in one platform such as windows phone and implement the code the way that is portable to other platforms like android and iOS regarding data binding?
Or I’d better ask if MVVM design pattern is common between different platforms?
It is based on the Model-View-Controller pattern, which is applicable to all platforms. MVVM is a variation based on the various DataBinding features in WPF. At least that's the context where the term MVVM is most commonly used.
While the pattern itself is portable, you won't be able to use your Windows Phone code for platforms like Android or iOS.
While the pattern might be applicable in different plattforms the implementation won't be (for example iOS's Objective-C / device-specific APIs vs. Windows Phones C# / Silverlight).
Only solution might be going HTML5/CSS/JavaScript - I think you might be able to use MVVM there but it's more a technology than an pattern thing.
There is an implementation of MVVM pattern using JavaScript and HTML (thus making it very portable):
http://knockoutjs.com
Since there are at least two very different platforms and libraries that allow you to easily use this pattern, the answer is YES.
I have to create now a multi-screen Silverlight 4 RIA application with MVVM.
Each of these screens has to be devided in multiple regions (for example master-detail scenario whereas each of them is a different section and one has control on the other).
Can you give me some ideas what should be the right way to implement such an application?
Is Prism the right choice? I started reading the Prism manual and liked very much the idea of having regions and screens switched and controls in a very flexible manner, but, as said above, I find it too overkill to split it all over many assemblies.
If Prism IS the right choice, then I would appreciate any kind of guidance or reference to guidance on this particular scenario (multiple screens & regions and OTOH not getting my solution spotted with a gazillion projects.
I believe that PRISM is the correct choice for building an application with multiple regions and views. You could argue that that is almost the definition of a composite application.
But I would also remember that you don't have to use all the components PRISM has, you can pick and choose. I would recommend that you consider each aspect of PRISM and test/prototype to ensure you are happy with the facilties offered. In a large application I have built I use PRISM but after some prototype investigations I only used EventAggregator and the Modularity capabilities.
I chose not to use the region support as I found working with ItemControl and ContentControl components in Silverlight gave me the ability to inject views and partial views into my interface.
I found experience from ASP.NET MVC proved useful in considering how to coordinate/break up my UI into partial views.
Hope that helps. The Stocktrader application is a great example to learn from (included with the PRISM distributable).