I know that MVC design pattern is popular, mainly in the web based apps. I'm curios to know how the MVC design pattern can be used in desktop applications environment.
To be more specific, let's consider the VLC media player. Can the VLC be written accordingly to MVC pattern? Who is M, V, C and who is the "dispatcher"?
Maybe the VLC isn't the perfect example, but I think it is a popular application. VLC isn't only about playing a video it has built in codecs and also some video effects adjustment support.
I think MVC doesn't get mentioned with desktop applications so much because a desktop app already follows the MVC approach. You have a GUI (your view) which has a series of interactivity points that cause events (call a controller).
Sticking with a simpler app:winamp.
Controller-Initiation Points:
Menu options
Buttons
View Points:
Total GUI
Track information panel (artist/track etc)
Visualization panel (graphic eq)
You certainly can use the MVC pattern for a desktop app - and will realize the same benefits as a web-app.
I've used the MVC pattern for non-web applications before. It's actually a really good approach for implementing a variety of interfaces to one application. In my experience:
The Models are pretty obvious; they don't change. In the VLC example, they could be things like input files.
The Controllers don't really have to change much either (if they're well written). Controllers should be basically agnostic to the interface-type (web, cli, etc.). A given controller action should be thought of as saying, "here is where you __ with the data."
The Views are where significant refactoring comes in. Simply re-create the views with input/output appropriate to the medium (e.g. windowing instructions, rather than HTML resources).
Finally, the "dispatching" in this case would be done by the application executable which would effectively be communicating messages -- translating user input (and other input) into calls to the controller (just as in a web app).
Check out Wikipedia's article on the MVC pattern for more info.
Related
Please help - I'm getting lost!
I'm writing a small desktop application which has some controls and some screen. This should later be integrated with a small web site, also having some screens. The idea is to let the user edit videos and select images, and then share their results with her friends.
The desktop app is using C# WPF, the web site - ASP.Net MVC.
I read that growing the application past a few screens would be easier using MVVM. So I started searching and discovered Caliburn.Micro and MVVM.Light. I have downloaded some tutorials but, just as I was getting ready to deep-dive into the material, I found here on S.O. that there's also Prism, MEF, Unity, ReactiveUI - This is becoming too much!
I'm terrible at learning new things - It's taking me ages to study WPF and ASP.Net MVC. I don't want to study lots of new material only to find out later that it's not relevant. And I don't have an architect to instruct me.
So my question is: Could you put these frameworks and technologies in perspective, and suggest which I should focus on studying and using (esp. what can be later used with Windows 8)?
If you want to build an MVVM application (which you probably do for various advantages), then you want an MVVM framework.
I would recommend Caliburn.Micro, as it is straightforward to implement following the examples on the Caliburn.Micro documentation page. It also has a very compelling convention over configuration mechanism, and uses an Actions system to invoking verbs (methods) on your view models from the view. This is more powerful than any other mechanism I've seen.
Prism is quite a heavyweight framework which includes elements of MVVM design to help the implementation, as well as being particularly tailored towards building composite applications (applications that are built up of decoupled components within a hosting shell).
MEF is useful for these types of applications that need to discover plugins or extensions to the application (even after the application has bootstrapped), and can be used alongside an MVVM framework such as Caliburn.Micro. MEF can also be used for implementing inversion of control, but doesn't provide some of the core features found in other inversion of control containers, so you may decide to only use it to implement plugin functionality.
Unity is an IoC container, and would be used to implement dependency injection for your general application infrastructure. There are lots of IoC containers in the .NET space though, some of which offer either improved performance, additional features, or a more friendly API.
I don't know about ReactiveUI as I haven't used it.
If you're talking about maximising code reuse for a move to WinRT, then MVVM is a great choice.
PRISM already include MEF and MVVM logic :)
Ok little bit of explanation here:
MVVM stand for logic in your application. Actually clever way of decoupling of View, View-Model and Model. Don't know any best (?) framework to do it - you could check Catel if you want or MVVM Light but it just a tons of code from someone who understand the MVVM logic and just make it easy to implement it. You could actually try to write your own MVVM framework and see that 'there's no secret ingredient' - just the same repeating code and same classes, etc... Actually you don't need any MVVM framework to implement MVVM.
Once you learn and write MVVM you immediately run into question - How I NUnit test it in decoupling way (this is not trivial problem in Silverlight for example) - so here all IOC/Inject framework come into play. For example MEF. Consider following example to understand a big picture about Inject framework:
Project 'Shared', written in 'least delimiter' (for example Portable Library)
public interface IAmSharedInterface
{
string SayHello();
}
Project 'Main', reference only 'Shared' project
public class IAmMainClass
{
[ImportingConstructor]
public IAmMainClass(IAmSharedInterface SharedInterface)
{
SharedInterface.SayHello();
}
}
Project 'Implementor', reference only 'Shared' project
[Export(IAmSharedInterface)]
public class IAmImplementor: IAmSharedInterface
{
public string SayHello()
{
return "Hello from implementator class to whoever using it";
}
}
You see - there's no direct reference between 'Main' and 'Implementator' projects - all 'magic' happens in MEF/Unity build/resolve process. So you could easily run NUnit test on Main without using 'Implementor' project and 'Implementor' with 'Main'. There's also a scenario where other project could implement and export 'IAmSharedInterface' specially for testing purposes.
So back to PRISM - it have all (!) this. I know it's not easy framework to understand right away and it doesn't suitable for simple 'Hello World' programs but once you learn it - there's no way back. It just glue all the parts together and give you big degree of freedom in using whatever moq framework you want (for example Rhino).
Prism developing in Microsoft so (I hope) it will be supported not just in Windows 8 but in Windows 9 and in all future versions.
Whatever you asked it's all inside: MVVM, Inject, decouple/plug-ins, easy to read and test
To save adding to the detailed information above, I'll attempt to make life easy for you.
1) For now, forget about IOC / Dependency Injection / Plugin architecture. You say you're creating a simple app, so forget about this for now. Keep your code tidy and you can implement this later if necessary (it's good stuff).
2) Out of the frameworks you've listed I would suggest Caliburn.Micro. It's relatively straight-forward and lightweight. It wouldn't take you long to get up and running.
3) Create your model in a separate assembly which you can use for both your windows app and your MVC website.
Keep it simple and don't get bogged down with all the technologies.
This answer reproduces some abridged chunks of Rockford Lhotka's Blog article "Using the MVVM pattern requires a framework" which was cited in another answer.
It is sort of a meta-answer to this question (though it does contain a specific recommendation), but it seemed very useful to explain the role of a framework in MVVM in the first place.
There are three fairly
popular presentation layer design patterns that I collectively call
the “M” patterns: MVC, MVP, and MVVM. This is because they all have an
“M” standing for “Model”, plus some other constructs.
The thing with all of these “M” patterns is that for typical
developers the patterns are useless without a framework. Using the
patterns without a framework almost always leads to confusion,
complication, high costs, frustration, and ultimately despair.
These are just patterns after all, not implementations. And they are
big, complex patterns that include quite a few concepts that must work
together correctly to enable success.
...
Trying to do something like MVVM without a framework is a huge amount
of work. Tons of duplicate code, reinventing the wheel, and retraining
people to think differently.
At least with a framework you avoid the duplicate code and hopefully
don’t have to reinvent the wheel – allowing you to focus on retraining
people. The retraining part is generally unavoidable, but a framework
provides plumbing code and structure, making the process easier.
You might ask yourself why the MVC pattern only became popular in
ASP.NET a few short years ago...
Strangely, MVC only started to become mainstream in the Microsoft
world when ASP.NET MVC showed up. This is a comprehensive framework
with tooling integrated into Visual Studio. As a result. typical
developers can just build models, views, and controllers. Prior to
that point they also had to build everything the MVC framework does –
which is a lot of code. And not just a lot of code, but code that has
absolutely nothing to do with business value, and only relates to
implementation of the pattern itself.
...
Typical developers really do want to focus on building models, views,
and viewmodels. They don’t want to have to build weak reference based
event routers, navigation models, view abstractions, and all the other
things a framework must do.
...
In the meantime, Caliburn Micro appears to be the best MVVM framework
out there – certainly the most widely used [as of 2012]...
(Text copied inline for preservation reasons.)
I'm interested in how to develop Web-GUIs using test-driven-development.
Especially I'd like to know if there are any guidelines/hints/best-practises on how to design Web-Frontends (i.e. the HTML) in order to be (automatically, of course...) testable? (in classical UI-developement there are patterns such as MVVC which support TDD and automated testing)
The are very similar patterns for web development as there are in desktop development. But, and it is a big one, the web is stateless. This sounds obvious but I think it clearly defines the boundaries for testing.
There are many, many popular incarnations of MVC for the web. However, in some web technologies it is hard to separate out pure UI (HTML, CSS etc) from code. You can always fall back on more of an MVP approach, which is like MVVM except the view is passive (won't respond to events and rebind). These patterns should cover you for the main UI logic of the application. All of these patterns can be used with TDD.
If you want to then go up a level, you are into tools like Selenium. These tools allow record/playback of user interactions with the web ui. However, if used casually, they can lead to brittle tests that break when the layout changes.
Hope this helps.
I don't know of any specific guidelines, but writing clean, semantic HTML and making appropriate use of CSS class and IDs is normally sufficient.
I want to develop an application which has a graphical user interface that could be developed by using different widget toolkits. For example I want to use Qt, GTK+ or even ncurses as a building block for my user interface for the same application. Moreover users could choose which GUI implementation will be used during the next startup of the application without recompiling it first. I wonder what are possible design strategies and design patterns used in the implementation of this design?
The classic design pattern for multiple GUIs is MVC.
You have one model (application data and rules), the controllers (one per view) - these control UI interactions and mediate between the UI (views) and the model.
You can have different views talk to the controllers - one view can be Qt, another GTK+ or even a console application.
Why would you want that?
Each toolkit has its own strong points and weaknesses. If you want to design something that will work with them all, you will be limited by the cumulative sum of all of the weaknesses and gain none of the strong points.
For instance if you're using Qt then you won't be able to use QT's signals and slots. that will make writing the GUI and the interaction with it quite painful. You'll basically need to write a whole wrapper layer around something that is already a wrapper layer (to the native APIs)
I see no possible reason why a user would care to choose between Qt or GTK+ or ncourses. just select one thing and stick with it.
I've done plenty of programming before for CLI and the web, however recently I am getting into desktop GUI programming.
Most of the tutorials for GUI programming I found just explain the different controls you can use and leave it at that. Some of the better ones also skim over a few usability issues.
However, my problem is not with the APIs, or the theory but with my code.
How are you supposed to organise different views your application might have (e.g. a IM application has a login view, a contacts list view, a conversation view etc.).
Are these supposed to be different classes or different methods on one class?
Different panels that are hidden and revealed, or different windows altogether?
I'm hoping for answers as language agnostic as possible, but in case that's not possible, the languages/frameworks I am considering are Java/Swing or C#/WPF. However, if there's another language/framework that is significantly better for learning from, I would consider using that.
Normally each view will be a seperate class in a seperate file. The class will then most likely implement some base class like Window or Control.
As far as organization, if it's a simple app, put them in the root or in a UI folder. Or perhaps a Window folder and Controls folder.
If it's a large app with several views, than break them out into functionality, i.e. an IM folder.
I would say go with what Joshua said and as far as using different panels that are hidden and revealed, i've worked on old code and it's a nightmare to re-use (8000+ lines of Delphi 6!) so stick with different windows as much as possible!
The generally recommended overall structure of the program is the model-view-controller (MVC) type of structure. So, first off, don't make the actual data part of the views, it goes into the model. From here, since the only data in each view window is now almost entirely just layout information and what to do on an action (click, data display, etc), if these are different, they should probably be different classes. If there's some general functionality that can be factored out, you can make this a base class and inherit from it, but in the end, windows with different functionalities should be different classes.
If you are going to be using one of the mainstream IDEs it will handle some of this work for you. The default will be a different class for each form. Hidden panels and tabbed interfaces are nice features but do yourself a favor and learn the ins and outs of embedding groups of controls into form. Some frameworks allow you to directly embed one form into another. Others have special containers that can be be embedded.
The point of these is to break up your functionality so you don't wind up with a bloated form class that's difficult to wade through.
I would also spend some time looking at some of the architectural patterns for keeping your business logic separate from your UI. Check out this link for a good starting point.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Note that I am not asking which to choose (MVC or MVP), but rather if one of the two should be used for a web application.
I realize that it might be too much work to convert an older application from its current design to a MVC or MVP pattern. However, what about for a new app? It appears these are the most popular architecture patterns, so should one of these be chosen? If not, what other patterns are there?
If you are not familiar with MVC and/or MVP, a good question to check out is "What are MVP and MVC and what is the difference?". It has many good answers, including links to various websites that break down each one.
MVP / MVC works well in web applications because the HTTP verb + URL combination is a very good way to determine which action to take. There are reasons not to use it, such as if your team has a lot of experience with another framework, but I would generally recommend an MVP / MVC framework. Your application will be finished quicker with higher quality.
Both are great options.
I'd go for MVC as it has a wider adoptions and its easier to understand and use to frontend (HTML / CSS) developers.
Also, given the number of frameworks adopting the MVC pattern, chanches are talking with your coworkers in MVC you will talk a well knew language.
Your question was "should I use one of these design patterns".
I'd have to say that that really depends on the scope of your project. On a very large project that has interdependencies with other systems in a large organization with a large budget, I'd say they are definitely worth considering.
I think these patterns are often over-used on smaller projects where they may add unneeded complexity and cost.
The main point of loose-coupling, is so that you can change your DB or UI at a later time, or re-use business logic. Often times, this never happens. You have to realize that either of these patterns will take longer to implement and complicate the code quite a bit. So, I strongly suggest really thinking this over and weighing your options. You can often deliver a better solution faster by using a very simple architecture that gets the job done and reduces complexity!
I have posted the following answer for another question, though it may be more appropriate here.
MVC is good for plain server side scripting. In MVC developers always try to keep the controller very lean. Mainly controller is for just selecting the appropriate model and reflect on the view. But in today's web applications the View part has radically changed and became complex enough to produce a big, fat and messy controller. So now we need a new place to put the user interface's complex control logic. Here the P of MVP comes in that is the presenter. So presenters are responsible for controlling the logic for a particular user interface component. Don't worry the controller is still here, named as Application Controller. Which ultimately responsible for switching between comparatively larger application components. So MVP can also be said MVPC(!!). BTW this was my way of understanding MVP and obviously not any ground rule.
So I am already tend to MVP for complex web apps.
It depends on the framework you're using. Just use what it supports.
Most web frameworks I've seen use the front controller pattern and call it MVC or MVP.
I think that you should. They are harder to implement, especially in MS world because they did everything to push Web Forms and make building web applications more easily.
Using them you are programming straightforward and you feel like you've done a lot of work. But they are slower and harder to maintain after your site gets bigger.
Using MVC and MVP allows you to separate model(basic classes that represent domain you are working with), controller and views. The best thing about that is that you can reuse your model in other applications like mobile applications or windows apps. They then have more in common than just a database so you have to write less code. You just have to write controllers and views.
I am new to this but I see benefits because when I had to change something on one place something else crashed elsewhere(so you also have to get loose coupling into account and writing unit tests). Writing tests is impossible in Web Forms.
However, if you are building application to represent a person or a company, where there is no business logic on the web, and you have to do it fast, Web Forms are good for it. And also for building prototypes so you can show what application will be able to do when finished.
I like both patterns. My best practice is to choose an pattern, that is always better then NO pattern.
I've developed many applications on both patterns, my personal feeling is that when you are an RAD developer and you are not so good with CSS & javascript(Mostly winforms developers who want's to create an webapp, no offense ;-) ) You should use the MVP pattern because this is very easy to use with the Web Application Projects.
But when you known allot of CSS & javascript then you should consider the ASP.NET MVC pattern.
I would prefer the MVC Pattern, just because the loose coupling. There is a clear seperation between model, view and controller and through the isolation it`s better suited for Test-Driven Development or just Unit-Testing.