I've recently asked a question on StackoverFlow about the MVC: Can the MVC Design Pattern / Architectural pattern be used in Desktop Application Development?
Based on the answer provided I started research on how this would be implemented in a Windows form Application. I came upon the following CodeProject article: http://www.codeproject.com/KB/cs/model_view_controller.aspx
In the comments below the article, certain users argue that (although this is a good article) it is actually the observer pattern. First, but less important, question is does anyone agree or disagree with that and why?
Regarding the second and more important question: I'm trying to build a small task list program in .NET. It will be very tiny and hopefully fast. In general, what would be a better architecture for such a project? The Observer Pattern or the MVC Pattern? Or another pattern?
Thank you
usually the model in an mvc (http://en.wikipedia.org/wiki/Model-view-controller) is an observable/subject (http://en.wikipedia.org/wiki/Observer_pattern#Subject), while the views are observers (http://en.wikipedia.org/wiki/Observer_pattern#Observer). also see: mvc in http://webcourse.cs.technion.ac.il/234321/Winter2005-2006/ho/WCFiles/08-Design-Patterns.ppt
(The article is not an example of MVC AFAIK for the simple reason that there is no controller.. it is more close to .net data binding if you ask me.)
MVC is not the Observer pattern. MVC is concerned with separation of concerns. The Model, the View and the Controller all do one job and trust the others to do theirs. In a way, the Controller 'directs' the view and tells it how to react to a change (Pure MVC). The controller also interacts with the model appropriately (whose responsibility is to encapsulate data and enforce constraints/rules). In MVC, the controller is the starting point for all activities - user input is received by the controller first.. However there are variants like MVP, where the user is input is received by the view first and then pushed/synched with the presenter.
The Observer pattern is where you want to watch another object for a change in state. So you could say .net events follow the observer pattern
If its really tiny, forget about patterns and just code it up without worrying about the architecture... Follow the heuristics/principles of good design
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
http://mmiika.wordpress.com/oo-design-principles/
If you run into design issues or it starts to get all messy, then bring in the pattern battalions.
I would agree that the article is not MVC. Its more of an implementation of observer pattern. Observer pattern in .NET can be implemented by using events, which was the case of the article.
MVC requires a controller class that controls what action to execute upon a request made from either the model, or the view. Applying MVC is a very good programming practice as it greatly promotes separation of concern. You will have a cleaner, more extensible, and more testable app with mvc. Another point to note, you can still apply observer pattern to an MVC app. They will not contradict each other.
===========
To answer your second question: which pattern is the best? I think the way you approach software development is rather wrong. You shouldn't worry too much about those things yet, not until you've hit a problem. e.g. If this object changes state I need these other objects to react to it, hence I would implement an observer pattern.
If I were you I would start on the model side first, and then takes things from there.
Related
Is it good practice to combine MVVM [angularjs,knockout.js]with MVC [JSF/spring].
Is it good way to control mvvm object/variables/ from inside JSF page.
Lets say I have to update a dropdown list in angularjs model by using jsf controller to fetch list object and update angularjs dropdown model. Is this a clean way or a junk way or is it just a work around.
I have to admit that I don't really know JSF or Knockout. However, I can easily imagine that because both sides want to be in charge of viewed components, a component based framework like JSF or Wicket might have trouble playing together with Angular. A couple things come to mind:
Why do you need the component framework from the server side? Why not use a request-based framework like Spring MVC or struts? They should work fine as they are just taking care of the overall page loading.
You will probably be ok if you decide to use one technology to do one thing. For example, do your page containers with JSF, and everything inside the page with Angular. I think you'll be ok with that. Of course, you are losing a big part of the benefit of JSF.
I'm actually doing this right now. I can't say what the best practice is, but we found that we needed to be able to output dynamic HTML from the server, even if you have an MVVM framework in the front end. Things like internationalization is better handled on the server side, and with purely static HTML from the server you run into a lot of limitations.
The main drawback is complexity. You will have controllers, models and views on the server, combined with controllers, templates and viewmodels on the client. This makes the architecture a bit confusing, especially as you bring new members into the team, so documentation and code structure becomes very important.
Overall, I think it's a valid approach. It hasnt bitten us yet, at least :)
Here's the content description for AngularJS page:
AngularJS is what HTML would have been, had it been designed for building web-apps. Declarative templates with data-binding, MVW, MVVM, MVC, dependency injection and great testability story all implemented with pure client-side JavaScript!
So what does MVW stand for?
(Considering the MVC, MVVW, MVP etc squabble, I would guess "whatever", Model-View-Whatever =P)
It stands indeed for whatever, as in whatever works for you per Igor Minar from 2012 (emphasis mine):
MVC vs MVVM vs MVP. What a controversial topic that many developers
can spend hours and hours debating and arguing about.
For several years +AngularJS was closer to MVC (or rather one of its
client-side variants), but over time and thanks to many refactorings
and api improvements, it's now closer to MVVM – the $scope object
could be considered the ViewModel that is being decorated by a
function that we call a Controller.
Being able to categorize a framework and put it into one of the MV*
buckets has some advantages. It can help developers get more
comfortable with its apis by making it easier to create a mental model
that represents the application that is being built with the
framework. It can also help to establish terminology that is used by
developers.
Having said, I'd rather see developers build kick-ass apps that are
well-designed and follow separation of concerns, than see them waste
time arguing about MV* nonsense. And for this reason, I hereby declare
AngularJS to be MVW framework - Model-View-Whatever. Where Whatever
stands for "whatever works for you".
Angular gives you a lot of flexibility to nicely separate presentation
logic from business logic and presentation state. Please use it fuel
your productivity and application maintainability rather than heated
discussions about things that at the end of the day don't matter that
much.
MVW stands for Model-View-Whatever.
For completeness, here are all the acronyms mentioned:
MVC - Model-View-Controller
MVP - Model-View-Presenter
MVVM - Model-View-ViewModel
MVW / MV* / MVx - Model-View-Whatever
And some more:
HMVC - Hierarchical Model-View-Controller
MMV - Multiuse Model View
MVA - Model-View-Adapter
MVI - Model-View-Intent
Having said, I'd rather see developers build kick-ass apps that are
well-designed and follow separation of concerns, than see them waste
time arguing about MV* nonsense. And for this reason, I hereby declare
AngularJS to be MVW framework - Model-View-Whatever. Where Whatever
stands for "whatever works for you".
Credits : AngularJS Post - Igor Minar
https://en.wikipedia.org/wiki/MVW
https://en.wikipedia.org/wiki/AngularJS
https://angularjs.org/
AngularJS — Superheroic JavaScript MVW Framework
https://plus.google.com/+AngularJS/posts/aZNVhj355G2
I feel that MWV (Model View Whatever) or MV* is a more flexible term to describe some of the uniqueness of Angularjs in my opinion. It helped me to understand that it is more than a MVC (Model View Controller) JavaScript framework, but it still uses MVC as it has a Model View, and Controller.
It also can be considered as a MVP (Model View Presenter) pattern. I think of a Presenter as the user-interface business logic in Angularjs for the View. For example by using filters that can format data for display. It's not business logic, but display logic and it reminds me of the MVP pattern I used in GWT.
In addition, it also can be a MVVM (Model View View Model) the View Model part being the two-way binding between the two. Last of all it is MVW as it has other patterns that you can use as well as mentioned by #Steve Chambers.
I agree with the other answers that getting pedantic on these terms can be detrimental, as the point is to understand the concepts from the terms, but by the same token, fully understanding the terms helps one when they are designing their application code, knowing what goes where and why.
I have a nice application written in Silverlight. To allow greater cross browser support, we are considering rewriting with a HTML5 front end.
What would be a reasonable way to move from Silverlight using XAML and C# with MVVM coding patterns into a HTML5 front end.
On the other hand, if this is not a good idea and the MVVM pattern should be abandoned, please explain why.
Knockout is a great javascript library which helps you to write MVVM client side. You create your view models in javascript and bind to them using html templates (with the help of jquery templating). Your view models can use ajax to retrieve data.
It is essentially the same as Silverlight development- you have HTML instead of XAML and javascript instead of C#/VB.Net. You could even use the same web services really...which might be helpful if you plan to offer both interfaces or conversion later on.
Edit
Thought that I'd add that IMHO MVVM should not be abandoned as it really does a great job of separating concerns (I guess when implemented correctly) but a big win surely is that it has the developer thinking about or in the mindset or separating responsibility in an application. I've used Knockout.js for web projects and Caliburn.Micro for Silverlight and have really enjoyed that style of development.
Knockout is MVVM pattern implemented in HTML/Javascript with databinding and all.
http://knockoutjs.com/
If what you want is achievable simply through DOM manipulation, and you're used to and like the MVVM pattern, Knockout should be a good choice.
Yeah, the MVVM pattern for HTML 5 is called MVC. Most easily implementable with MVC3. Provides a layer of abstraction in respect to the JavaScript code, support for ViewModels (aka Views) and separation of concerns between the views, data access, and business logic.
Best of all is that validation and UI event handling is wired for you in a simple manner, allowing you to abstract yourself from the intricacies of JavaScript event handlers for various HTML controls.
However if you strictly want to stick with HTML & JavaScript, I suggest rolling your own JavaScript classes (yes JS is functional language, but you can still make those) that represent your UI layer and handle UI events. Then create your own Ajax library for getting JSON serialized data back and forth from the UI classes to the server back end. Finally create your own business logic classes (also in javascript) to control your UI and DataAccess (ajax) classes. In short.... lots of dirty work.
There is also the experimental Model Driven Views (MDV) library from Google.
Unfortunately, it is only intended as a prototype showcase. Conceptually, it is really cool, but be prepared to do some bug fixing on your own.
http://code.google.com/p/mdv/
There is also JSViews. This one is not as slick as Knockout, but it is faster at updating the DOM. The project is loosely related to jquery as its author was behind the now scrapped query templates.
When I gloss over the backbone.js site, I'm not sure what is it trying to do.
It seems somewhat popular, but why should I want to learn it? What will it do for me? Why was it made? What problem does it solve?
I find the question perfectly valid and from my point of view there is nothing wrong with inquiring about the potential use cases of a library/toolkit.
What Backbone.js does (so do several other javascript mvc implementations) is that it provides a means of organizing the code into a modular pattern known as MVC pattern which is all about separating your code into three loosely coupled layers:
Model layer dealing purely with data and associated operations
View layer being the presentational aspects
Controller layer being the binding glue layer
(different frameworks deal with this differently : Backbone implementation of controller layer comprises of client side routing capabilities).
So, on the whole backbone provides you an infrastructure using which you can deal with data through models which contain encapsulated within them the data and associated validations, which can be observed ie. you can bind events to change events.
The View layer is mostly left for the user to separate the ui into manageable isolated sections.
Here are some problems that Backbone solves for me in the JS/HTML space:
Separation of Concerns (SoC)
Composability
Testability
Component Model
Abstraction
That is not to say that this is the ONLY system that does this. There are others. Backbone does a pretty good job of helping with these things, though.
From backbonejs.org
It's all too easy to create JavaScript applications that end up as
tangled piles of jQuery selectors and callbacks
And that's exactly what backbone does, a series of callbacks on model changes and jQuery selectors to bind events.
So to answer the question, it solves nothing only to provide a way (the backbone way) of structuring code with some slight automation in the REST side of things.
we have a rich client application written in WPF/WCF and are intending to create a companion website in ASP.net (using MVC if possible).
I've been asked to figure out how much of our current codebase, we can reuse (by a separate team) - and I have little to no experience with ASP.net.
We will reuse our domain model, but is there any point in separating out the WPF-specific parts of our ViewModels and reuse the WPF-agnostic parts in MVC? Does it even follow the same paradigms? We use RelayCommands exclusively for commanding, so it would be easy to wrap the contained methods in something ASP.net specific... But how about UI-specific things - e.g. does ASP.net use INotifyPropertyChanged - or how does it handle UI-updates?
For me it wouldn't make any sense. Your models should contain all of your important business logic code and should be the point of greatest reuseability. Your view models should contain presentation logic only, and as this is so different for a desktop and web app, it doesn't make sense to reuse these.
MVC does not use any binding mechanism for UI updates, as web apps are stateless by nature. You will actually most likely end up using view models for your MVC app, but in MVC these act as simple data transfer objects (DTOs) for providing data to the views for rendering for each HTTP request. Once the view is rendered, you would need to go back to the server to update the view model and rerender the view.
Alternatively, you can of course update the UI client side with scripting. Knockout.js is a nice JS library for client side view model/view binding.
I can't directly answer your specific question because it depends highly on your application and the way your existing view-model is written but the question you raise is an interesting one.
On the one hand, the logic that the view-model contains very little view-specific code is a tantalizing argument for reuse. On the other hand, the view-model very clearly serves the needs of the view and expecting it to serve the needs of a different view could be problematic.
In the end all we can give are guidelines. You certainly don't want a monolithic view-model with ifdefs or ifs all over the place. You could refactor common functionality into base classes -- that's the object-oriented way -- but without good unit tests it's sure to break something in your already working code. But not doing that means having distasteful cut-and-paste code that is almost the same and likely to diverge creating a maintenance nightmare.
Perhaps a practical approach is to assume you'll need a whole new view-model but to review your existing view-model for code you can push down into the model before your start, thereby making the view-model as small as possible. Then at some point, maybe after you get a prototype working, you could attempt a merge to see if it is practical and what issues arise. If it can work, take those issues into account as you continue implementation and then plan the two tasks according to your needs.