I am building the User control in mvc. I want to write the controller for the user control where actions should access the WCF web service and its methods. What i need to do. is MVC3 supports bussiness logic classess for User control like normal asp.net supports .cs file as code behind to user control. I don't want to write any server side code in .ascx file. what should i need to do ?
some how usercontrol should be generic with isolated business logic.
This question has been asked an answered here. MVC 3 does not preclude you from using web forms approach that you are used to. But anyone one would benefit from using Razor, which is large paradigm shift from the use of webforms and takes a very different approach to the concept of reusable controls.
Related
We've been working on web solutions for over past 9+ years and just like many of you, we've migrated from the legacy ASP to ASP.Net, MVC, knockoutjs and so on. jQuery played a keyrole and now it seems its the age of MVVM libraries like KO with declarative data binding based approach.
I'll stop here and ask for expert opinions on our two requirements -
An editable grid with inbuilt sorting, paging and basic search. And if possible a grid capable of handling its own editable dialog (i.e. like datatables.net - but its paid)
Is there a way to take the declarative binding to the next level and auto-generate forms backed with knockoutjs like data-binding technology.
I believe no need to mention that we're working in ASP.Net v4.0+ and MVC. Most of our forms are backed by one or more table(s) and we can easily manage the backend CRUD operations once the correct actions are triggered from front end and we can have requests serving JSON as and when requested.
PS: We don't need the old school approachs like the #Html.EditorFor in MVC.
Can anyone explain difference between
MVC(Model-View-Controller)
and
MVVM(ModelView-ViewModel) architecture
?
Since MVC and MVVM are geared towards different application paradigms altogether, i.e., ASP.NET MVC for web and MVVM desktop, they need to behave in distinctly different ways, with the most noticeable distinction being the controller from MVC and the ViewModel from MVVM
The controller in MVC accepts HTTP requests, fetches data from the model, and routes that model to the view for output. In a desktop app, there is no routing or URLs; but desktop apps still feature navigation, which is part of the UI and therefore needs to be part of a good UI pattern. ViewModels are the piece that accomplishes this task, as the ViewModel in MVVM takes the responsibility of performing, or exposing the command that house all the UI logic in addition to fetching the data and data binding.
Views must behave differently as web and desktop applications use very different ways to render information for user interaction. Additionally, applications over http are considered stateless, whereas desktop applications have full connectivity over a LAN and contain and transport lots of data easily. Views in MVC only display data and perform basic client side UI duties usually with JavaScript (form submission, validation, effects, etc...). On the other hand, View in MVVM have a rich databinding and validation framework, when combined with the business logic and navigation exposed by the ViewModel, lead to a very rich User Experience
Models behave the same way in either pattern - they're full of data (and sometimes logic). You may want to use other patterns at the model level for better code organization, maintenance, and a finer separation of concerns. The repository pattern with Entity Framework is a popular pattern, and Julie Lerman has a great explanation within series of posts on it.
Within both MVC and MVVM exists the ViewModel. Despite the same name, there are marked differences within how ViewModels in either pattern work.
There are ViewModels in MVC, but they have different responsibilities than an MVVM ViewModel.
An MVC ViewModel is two or more models combined (smashed together), or a customized subset of a model or models that provides all the information necessary to its corresponding view. It's basically a hybrid model, and the best part - the views don't know the difference.
In MVVM, the ViewModel serves the same function as it does in MVC, but it also takes on the responsibility of a controller.
MVC Model and MVVM Model
MVVM is based on the MVC design patern.
MVVM is an implementation more specific for UI development platforms.
The separation between the development of the GUI and the development of the back end makes the development process more easy in these UI development platforms.
For more info on the difference, another topic already exists on this: Link to another stackoverflow topic
To my understanding, MVC is a way to implement the separation of presentation tier from business and data tier. Am I understanding this correctly? If so, MVC should separate the business logic completely from presentation, right?
So to me it seems like javascript (or jquery) is somehow violating the MVC design since it takes over some of the logic on the client side, isn't it? Is model = data tier, controller = business tier, view = presentation tier? I think I have misunderstood the whole concept.
You seem to have a decent understanding of MVC. The trouble is that you are looking at two different potential MVC structures as one and the same. On the server, you can have data models, controllers, and views. On the client side, you can ALSO have data models, controllers, and views. If you want to look at your client side JavaScript as MVC, then jQuery is simply a utility that the view controllers can use to manipulate the view (the DOM).
Simply put, the client side doesn't always have to be only the view. If you use a web application client-side framework like Backbone, for example, then you can have models, views, and controllers all on the client side, which communicate with another, SEPARATE MVC structure on your server.
What you describe does actually pose a challenge for a lot of implementations. Frameworks such as the ASP.NET MVC Framework have been making attempts to auto-render JavaScript to the UI based on business logic in the middle tier (validation rules for form fields, primarily). But they're a long way off from having a truly compelling JavaScript user experience which doesn't repeat logic.
Personally, I like to think of the JavaScript as purely a UI concern. The application internally handles all of the logic. The JavaScript, as part of the UI, may duplicate some of that logic... but only for strictly UI purposes. Remember that the application should regress gracefully into a still-working state if the user has JavaScript disabled. That is, it should still use server-side (middle-tier) code to get the job done. All the JavaScript did was add a richer user experience to the UI layer.
JavaScript isn't the only culprit for this, either. Suppose you have a lot of validation logic in your middle tier defining what's valid or invalid for your objects. When you persist those objects to a database (which is on the periphery of the application just like the UI is), doesn't that database also contain duplicate validation logic? Non-nullable fields and such.
Congratulations! Your understanding of MVC is completely wrong. It has nothing to do with n-tier architecture (which is what you seem to be confusing it with).
The core idea of MVC is separation of concerns. This is used by dividing the application it two major layers:
model layer: contains all of the domain business logic and rules.
presentation layer: deals it user interface
The presentation then is further split into controllers (for handling the user input) and views (for dealing with response).
When applied to web applications, you either have MVC (or MVC-like) structure only on server-side, or, for larger and more complicated applications, you have separate MVC triads for both frontend and backend.
Also, when working with applications, the user of MVC is not human being, but the browser.
In latter case the backend acts like one data source for frontend application. An the whole frontend part of MVC is written in javascript.
P.S. In case if you are able to read PHP code, you can find a quite simple explanation of model layer in this answer. And, yes. It is the "simple version" because MVC is a pattern for enforcing a structure in large application, not for making a guesbook.
You can go to http://www.asp.net/mvc site and refer tutorials / samples to learn about MVC using Microsoft technologies.
The best thing I like about ASP.NET MVC, is that you can directly call a server method (called action), from the client. This is so convenient, and so straightforward, that I really like to implement such a model in ASP.NET WebForms too.
However, in ASP.NET WebForms, to call a server method from the client, you should either use Page Methods, or Web Services, both of which use SOAP as their communication protocol (though JSON can also be used).
There is also another substitution, which is using Generic Handlers. The problem with them however is that, a separate Generic Handler should be written for each server method. In other words, each Generic Handler works like a simple method.
Is there anyway else to imitate MVC model in ASP.NET WebForms?
Please note that I can't change to MVC platform right now, cause the project at our hand is a big project and we don't have required resources and time to change our platform. What we seek, is a simple MVC model implementation for our AJAX calls. A problem that we have with Web Services, is the known problem of SoapException, and we're not interested in creating custom SoapExctensions.
You can mix ASP.NET MVC and ASP.NET Webforms in the same project. You'll just need to add the correct MVC parts to your current Webforms project and have the best of both worlds.
http://www.aspnetmvcninja.com/general/mixing-asp-net-mvc-and-webforms has a good walkthrough of all the steps you'll need to take to get it working.
You can splice your asp.net webforms app with something like Nancy perhaps?
I've had great success with Nancy and Knockout after I abandoned the horrible Ajax Control Toolkit.
(Apologies if I have misunderstood your question - I read it twice)
I'm working in a Banking Online Platform written in WebForms and I'm wondering if the same could or should be written in MVC.
I've read a lot on MVC but i didn't tried yet but i must ask a question for the experts.
Every transaction has a 3 Stage Process where the users input the data, review the data and gets a 3rd step where get's the confirmation. I currently have 40+ processes like this. The way i do it? Single ASPX with MultiView.
How can i do the same in MVC? Would i have 40+ x 3 Views (120+ aspx) ?
Thank U all.
The same can be achieved in MVC by using partial views.
MVC has full control over the rendered HTML and JavaScript frameworks is much easier to implement. It is also a lot more easier to write unit tests.
It is also 'lighter' in the sense that it does not have any View State events (which is the thing that makes Web Forms big when working with big data)