I have a query regarding MVVM and MVC. I am developing an Desktop Client and Web application. I intend to use WPF (and MVVM) to develop desktop client and ASP.Net MVC for web app.
I have never used ASP.Net MVC before although I have never truly liked Web Forms (except some features like Master Page, output Cache etc.) and I mostly use AJAX (jQuery), and handlers to populate HTML and processing inputs (I think I was close to MVC after reading about the pattern but in a different way).
Now these applications will mostly have same inputs, reports, and database. I am planning to create Model that can be re-used in MVVM and MVC both. But after reading various articles on these pattern, and analysis of ASP.Net MVC Code, I doubt that it could be done. In MVVM, View never knows Model while in MVC, Controller shares Model with View. Also, in ASP.Net MVC, a View (ASPX file) is derived from System.Web.Mvc.ViewPage and the labels/captions are populated from Model itself.
Is there a way I can use same Model for both applications?
Thank you.
Ritesh
In MVVM, View never knows Model while in MVC, Controller shares Model with View.
Not quite right. In MVVM the view is bound to a view model. Exactly the same as in ASP.NET MVC. In ASP.NET MVC a Controller doesn't share a Model with the View. It shares a View Model. It talks to the Model and then builds a View Model that is passed to the View.
Contrary to MVC in MVVM the View could talk to the Model but this happens indirectly throughout the View Model, so neither the View nor the Model know about each other's existence.
So you could perfectly fine have the same Models in both your Desktop client application and in your web application. The only difference will be the view models.
Related
I wanted to know the difference between asp.NET MVC and MVP, are they both same?
below is the architecture diagram I referred.
(Image URL:http://msdn.microsoft.com/en-us/library/ff647859.aspx)
the major difference I got to know between MVC and MVP from the diagram is, in MVC the Model updates the view and in MVP the Presenter updates the view.
But here is my confusion.Below is a asp.net MVC code sample.
public class HomeController : Controller
{
//
// GET: /Home/
public ActionResult Index()
{
return View();
}
}
here the Controller returns/updates the view so now according to the diagram it is MVP
Is asp.net mvc and MVP similar? if not what is the difference ?Can someone guide me.
Actually MVP is a subset of MVC pattern.
In your example of asp.net mvc the controller does not updates the view rather it just pass the model to the view and the view get updated according to the model.
But in MVP (which is usually used with winforms and webforms in Microsoft stack) the presenter get data from view, updates the model and when the model changed, the presenter will read the model and updates the view.
That MVC diagram looks misleading to me. I would regard this as a more actuate architectural diagram:
this is from a PHP site but here you can clearly see the relationship between the view and the controller.
The differences between MVC and MVP are subltle, this question (as mentioned above) clarifies those differences.
That MSDN page also clearly says
This content is outdated and is no longer being maintained. It is
provided as a courtesy for individuals who are still using these
technologies....
I think this resource pre-dates Asp.Net MVC.
The articles themselves are for something call the Composite UI Application Block and are from 2005. I'd go to http://www.asp.net/mvc/ for some more up to date and acurate information on MVC.
No.They are not the same. They are two different paradigms (design patterns) used for user interaction. Based on these paradigms, ASP.NET team developed two different frameworks for writing web applications. The first is ASP.NET Web Forms based on an event based form programming. The second is ASP.NET MVC which is based on using Model Views and Controllers (MVC).
I suppose you could start reading here which is written by one of the ASP.NET development team members.
Regarding the specific question. I think that the Controller updates the View using the Model to do it. Model does not do anything. Or this is the way I understand it, anyway...
Hope I helped!
Try to understand MVC and MVP concept without connection to any technology.
Action method in ASP.NET MVC controller returns ActionResult with View method doesn't break any pattern. It just say that controller functionality is done and let's render the view from markup with Razor/ASP.NET syntaŃ….
In ASP.NET world - ASP.NET MVC is impelemntation of MVC pattern. Forgotten Web Client Software factory is MVP implementation
While I'm reading the book "ASP.NET MVC 4" I'm wondering about MVVM. I started googling and cannot find any books about developing web applications using MVVM, so I must be missing a bit of information here.
From what I understand, MVVM is used in web applications on the client side via knockout.js and other frameworks.
If however I was to develop a Windows Phone application, I could use MVVM directly without using MVC.
Does that mean, the concept of MVVM / data binding just does not apply to client-server web applications?
MVVM is really sort of a subpattern. There's not really any "MVVM" web app frameworks out there. They're all MVC and you pretty much just incorporate a view model if you want one.
With ASP.NET MVC, in particular, you just create a class, generally with a name in the form of [Model Name]ViewModel or [Model Name]VM. That class will have only the properties from your model that you'll need to work with and anything extra that doesn't make sense to put on your actual database-backed model, like SelectLists, etc.
In your action, you just pass an instance of this view model to your view instead of your model:
return View(viewModelInstance);
And, of course, make sure your view accepts that:
#model Namespace.To.MyViewModel
The only slightly complicated part is wiring the view model to the model (i.e., getting data to/from the view model/model. You can do this manually by explicitly mapping the properties, or you can use something like AutoMapper.
MVVM is the standard design pattern for WPF/Silverlight development, and should not be confused with MVC for ASP.Net development.
The two may sound similar and share some common parts, but they are two different design patterns.
From what I learned about knockout.js, it was designed to create "data bindings" similar to what you would use in WPF/Silverlight development, which is why the MVVM design pattern applies there.
To quote from another answer of mine regarding the differences between MVVM and MVC
In MVVM, your code classes (ViewModels) are your application, while your Views are just a pretty user-friendly interface that sits on top of the application code and allows users to interact with it. This means the ViewModels have a huge job, because they are your application, and are responsible for everything from application flow to business logic.
With MVC, your Views are your application, while your Controller handles application flow. Application logic is typically found in ViewModels, which are considered part of the M in MVC (sidenote: the M in MVC cannot be considered the same as the M in MVVM because MVC's M layer contains more functionality than MVVM's M layer). A user is given a screen (View), they interact with it then submit something to the Controller, and the Controller decides who does what with the data and returns a new View to the user.
MVC is a one-way data-binding system.
Fill your Model in Controller, then pass it to View.
MVVM is a two-way data-binding one.
Fill your Model, use it in View, when the View state's changes, your Model update automatically.(Vice-versa)
Does that mean, the concept of MVVM / data binding just does not apply to client-server web applications?
No, you can apply the MVVM pattern to client-server web applications.
In fact Asp.Net MVC actually kind of does use this pattern - when the controller creates the view, it can pass in a "view-model". This view-model is often a POCO data object with all the data that a particular view needs, drawn from the model (database). The view uses this data to render the html page.
MVVM on wikipedia says it was introduced by Microsoft with WPF. Specifically, the view binds to properties on the view-model. The view-model then maps this to the database. By this definition then, Asp.Net does not exactly match that. Client-side frameworks like knockout.js and vue.js do support this kind of 2-way binding with view-model properties.
All these patterns are based on the fantastic MV* pattern. It was originally called the MVC design pattern. So this is the exact same pattern as Asp.Net MVC then? Actually, not quite. Controller means something completely different to start with (see MVC on wikipedia). The original MVC controller handles all user input directly not via the view. Second, the original MVC pattern was designed for a desktop app GUI and Asp.Net MVC adapted the pattern for use in a client-server web app. An ASP.Net controller is a collection of http end-points which the client-side html page can hit (eg form-post, page-navigation, ajax).
So there are a lot of M-something-V patterns and the general pattern is often called the MVC design pattern.
There's one more important wrinkle: client-side vs server-side. We've introduced rich client-side javascript frameworks and the fantastic MV* pattern is great here too. So now we could have something like: client-side View-Model-ServerHTTPEndPoints and server-side ServerHTTPEndPoints-ServerModel. The server-endpoints refers to Asp.Net controllers or the equivalent in whatever web framework or programming language you are using. From the server-side point of view, the entire client-side html is the view. The client-side model talks to the server ajax api (http endpoints) to sync data or trigger advanced actions. The ServerModel is normally a database. In knockout/vue, instead of client-side "Model", it would be ViewModel. If you use react/vue with redux/flux then the client-side would be View-ViewModel-Model-ServerHTTPEndPoints where the Model would be the redux/flux Stores. Also, often on the server-side, a service is introduced: ServerHTTPEndPoints-Service-Model. This way unit tests can hit the service directly rather than firing up the entire web server and making HTTP connections.
I have used MVVM in desktop applications and I have a property in my viewmodels named Model where I store a business object as the model. My views have a property named DataContext where the viewmodels are stored before the views are loaded. A view bind its controls to the business object using the path DataContext.Model.BusObjPropertyName. I have a UserInteractionService that register from the start the relationships between views and viewmodels. When a viewmodel needs to show another viewmodel, it calls the method ShowView in the UserInteractionService and pass the viewmodel as parameter. Then the service instantiate the view corresponding to the viewmodel received, set its DataContext property with the viewmodel and show it.
If it is possible to do the bindings to a path like that above in Asp, all this model can be reused either in desktop as in Web applications.
I wanted to ask if anyone has tried using combination of Sencha's ExtJS 4 (using MVC approach) with ASP.NET MVC (using view models)?
I have existing ASP.NET MVC 3 app that uses view models and my question is how would this "fit" into Sencha's MVC approach...Would ASP.NET MVC "view model" become ExtJS "model" and then I would define yet another "view model" for ExtJS....Seems a lot of "translating"...
What would be the best approach?
And yes, I am aware of projects that integrate ASP.NET MVC with ExtJS using Ext.Direct, but my question is strictly relating to MVC paradigm on "both" sides (ASP.NET and Sencha ExtJS)
Thanks
Z...
Our approach currently is a what could be described as MVCCM or MVC-CM.
In ExtJs you have the view as panels and boxes etc, a store with a model makes a model and you need some logic to make these components work together which would be the controller.
This ExtJs frontend is situated in a MVC3 project and exposes controller methods that typically returns Json data which it gets from the model back end which is typically made up of entities.
There is no programmatic link between the entities on the server side and the models defined in the stores client side. One could generated the stores from entities, but we have not looked into this yet.
The view in the Microsoft MVC3 framework is just a page that returns some div tags which ExtJS can render stuff into.
While I've not done this with ExtJS, I really don't think there's any conflict. I'm assuming a lot here, I know, but if ExtJS works with JSON and you've got ASP.NET MVC actions that emit JSON, it's really more of a philosophic difference than a technical one.
One difference from a normal MVC app would be that your ASP.NET MVC app might not have any views, since the views would be handled entirely by ExtJS.
From the server side, ASP.NET MVC really doesn't care - it's getting a request that gets mapped to a controller and action, processing the request and returning some result. Whether that result is HTML, JSON, XML or whatever, ASP.NET doesn't care at all.
ASP.NET also has UI, Event Handling and if good logic layer is implemented then the BLogic layer too. So that can we say its Model View Control style. Or its not that ?
No. ASP.NET Web Forms is an implementation of Page Controller pattern.
Chapter of Fowler's PoEAA about the Page Controller on Google Books
As a pattern MVC is more concerned with the idea that the controller orachastrates the view and the model.
In Web Forms there is no controller. The View and the code behind (closest thing to a controller) are inherently the same thing, there is no separation of concerns.
Also depending on how you go about it, the model part of the MVC isn't necessarily your business logic. For us its literally a View Model, and contains data relevant to the specific view only. Business logic is handled in autonomous components.
With traditional web forms, I generally see the code behind (which is really part of the UI) having intimate knowledge of either business logic or data base access (and often a mixture of both).
Due to code behind it is hard to get away from this.
In my mind web forms create tightly coupled UI and business logic, and don't provide an easy way to enforce separation of concerns.
I'd say web forms does not adhere to the MVC pattern.
In MVC, all requests are routed to a Controller.
In ASP.NET all requests are routed to a Page. That is a View and not Controller.
ASP.NET better matches with MVP rather than MVC. Reason being, in MVP, a View is supposed to process user inputs/requests and pass it on to appropriate Presenters.
What are the basic differences between classic .cs-aspx.cs-aspx (code behind/beside) model and new MVC model?
The basic difference between MVC and classic ASP is that in classic ASP all of the code and mark-up for the application exists in the .asp file. In MVC the .aspx file contains only the code and mark-up for rendering the page. The rest of the application for handling requests, retrieving model data, and enforcing business logic exists in controller and model classes. These classes can be much more easily tested than class ASP code because it is separated from the code that is responsible for rendering the view.
This separation of concerns is the basis of the MVC pattern. According to the pattern, the code is divided into three major components -- Model, View, and Controller. Classes in the model represent the business objects for the application, the persistence framework, and business logic applied to the business objects. Classes in the controller accept incoming requests, use the inputs or query parameters to retrieve the appropriate model data, and generate the necessary data for the view to render. Views (aspx pages) take the data supplied by the controller and generate the mark up.
Webforms (codebehind) is somewhere between classic ASP and the MVC pattern. Webforms does not enforce the separation of concerns in the way that MVC does, but it does allow much more of the code to exist "behind" the actual page. For example, you can separate out the business objects, business logic, and persistence framework (the Model, if you will) from the code that is responsible for generating the view. The difficulty is that the controller actions (input handling and model retrieval) are still linked with the view rendering code. This integration makes it much more difficult to test this code and makes the view/controller code much more dependent on each other than is necessary -- the concerns are "mixed", not "separated." In general, this is evidence of bad design because it make it more difficult to make needed changes in the future.
Hope this helps.
Simply put it this way: MVC is how really web apps should be built. Code-behind (asp.net web forms) is not a good practice. If you are truly a developer you will appreciate that the MVC is the best practice since it really separates logic from data and presentation. Simply MVC is the elegant and right way.
A really simple way to perceive the difference between MVC and ASP (or ASP.NET forms for that matter) is that in MVC the Controller is the handler of the request.
Requests get routed to a controller not a 'page' or a 'form'. The controller will pass along info in the request to the model then make some simple choices as to which view that should be used to present the desired state of the model. Note this is the important point the controller has a choice of what view to use in the response.
MVC breaks the relationship between the requested URL and the UI code needed to render a particular representation of data.