Can it easily be combined with jQuery, (ASP.NET) Ajax, ASP.NET webforms, other frameworks.
What about pulling dynamic code from ASP.NET MVC into for example classic ASP?
Does the MVC model mean that it is easy to customize code?
Background:
I have some experience that it can lead to problems to integrate frameworks relying on JavaScript with each other?
We have a classic ASP where we write new stuff in ASP.NET, and include .aspx code in the ASP files.
I am looking for some OS frameworks for stuff we need, and i think MVC based ones should be easier to adopt (KIGG)
ASP.NET MVC ships with jQuery as the default javascript framework, so no worries there. There aren't really any ties in the framework itself to jQuery so you could also switch it out with a framework of your choice. MVC comes with it's own AJAX implementation that builds on the base ASP.NET Ajax implementation (at least in javascript), so there is AJAX support but I think you'll find that it's different -- no UpdatePanels, for instance -- but you're able to do similar things.
You can mix WebForms with MVC, but you'll need to set up IgnoreRoutes for those URLs so they don't get processed. I confess that I haven't found a need to do this yet, but then I don't use third-party controls. That might be an area where, at least for now, you still need some WebForms. I've never used classic ASP and likely won't so I can't help you there.
You can use any Javascript framework with MVC, they have included Jquery as the default but any can work with it.
As far as flexibility, we have deployed a working site with ASP.NET webforms, MVC and .NET 1.1 libraries, so yes it is flexible.
In our experience ASP.NET MVC is the best thing MS have done for web development, especially if you like to control closely your html output and use web standards in your layout and design. We have used it for 6 Months and we are NEVER going back to web forms.
Have fun!
Related
ASP.NET MVC 4 has some nice mobile features which are replacing my mutant mobile view engines, but until it's production ready, I'd like to implement the browser override feature for ASP.NET MVC 3.
SetOverriddenBrowser() seems to set a .ASPXBrowserOverride cookie with an overriding User Agent that returns an HttpBrowserCapabilitiesBase object via HttpContext.GetOverriddenBRowser().
What would be the simplest way of implementing this feature for MVC 3 to make use of the mobile detection library, including 51Degrees.mobi?
There is a blog post on the 51Degrees.mobi site that you might find useful. Check it out here. It covers the implementation of 51Degrees with MVC 4.
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)
Here's the situation. We're adding a new application to our suite of webapps based on WebForms and so I felt this would be the perfect time to introduce MVC.
I did all the research about intermingling the two and got the project all set up using an Area that uses MVC routes while the rest of the (visual studio) project runs with web forms the way it's been running.
Master pages were converted to Razor layouts, not too bad because there was only one master page that was shared between every application.
The problem I've run into now is reusing user controls. We have dozens of custom user controls, many of them fairly complex, that are reused throughout all of our applications. Most of them (especially ones that would be difficult to port) do a fair amount with ViewState and postbacks.
If it were just a matter of rewriting these in MVC, the one time cost would be less than ideal but not terrible. But since the existing apps need to be maintained and updated as well, it seems like maintaining 2 versions of the same behaviour using entirely different paradigms would be a huge drain on productivity.
My gut says there isn't really a good solution and we may have to abandon the idea of going to MVC for this project and stick with webforms, but I wanted to see if the SO community has any insight on what to do in this scenario.
If you have the budget to rewrite those server side controls using the MVC paradigm that would be the best way to go. If not, you could still embed them into existing classic WebForms pages and which would communicate with the new MVC application using standard HTTP/HTML techniques: form posts, sending ids through query string parameters, iframes, cookies, HTML 5 storages, etc... One thing's for sure though: try to avoid putting those server side controls in your MVC views. You will end up with some hybrid application that is neither proper ASP.NET MVC nor a proper WebForms which would be a disaster.
Personally I had to do this same migration multiple times and I didn't bother mixing classic WebForms with MVC in the same application using Areas or some other techniques. At the end of the day it might turn into a nightmare trying to make those two exist together. It's always one of the two: I have the budget and I rewrite from scratch properly or I don't have the budget and I do the new stuff properly using ASP.NET MVC and try to interact with the existing application.
I find it easier to simply start a separate MVC application which depending on the interaction I am looking for would use different methods for integrating functionality from the existing WebForms application.
I am not quite familiar with the complexity and details of your scenario so it is difficult to provide an objective answer but the possibility of continuing to write new code based on the existing WebForms server side controls and not doing any MVC at all for this project might also be a good solution. Writing a new application on ASP.NET MVC just for the sake of it might not always be the best choice.
Asp.net MVC 3 preview 1 was released at the end of last month. Are there any new features you are excited about or any features you would like to see before it is fully released?
Full support for Controllers with Generic Parameters
public GenericController<SomeType> : Controller
Generic controllers are quite possibly the greatest MVC timesaver if your doing a lot or business CRUD. There are so many similarities between the Add methods of almost every MVC project that it makes sense to abstract these operations out in a Controller that fits all scenarios.
Right now its a little hacky to create a generic controller. The MVC engine always gets the name wrong (GenericCo vs. Generic) and without full support plugin and libraries that interact with controllers just fall over when they encounter a generic one.
Make Dropdowns easier to work with
As a professional MVC tag watcher I've noticed that working with dropdowns is one of the most repeated questions on SO. The amount of Dropdown questions is a strong indication that something should be done to make it easier or less ... complex?
make checkbox list easy to work with
add T4MVC to the official release
add official helpers for OData
support one javascript library either MS Ajax or jQuery(preferably)
I wish they can add something to help developer to migrate their previous ASP.NET WebForms application.
Seems like every project I'm on uses a Model View Controller architecture, and that's how I roll my own projects. Is there an alternative? How else would one create an application that has persistent storage and a user interface?
MVC has been around for a while. It's a time tested and proven pattern. Many frameworks leverage the MVC Pattern. Martin Fowler has deconstructed the MVC into: Supervising Presenter and Passive View.
Architect Christopher Alexander said it best:
Each pattern describes a problem which
occurs over and over again in our
environment and then describes the
core of the solution to that problem,
in such a way that you can use this
solution a million times over, without
ever doing it the same way twice.
I'm not sure why you would want to move from MVC. Is there a problem you are encountering that MVC does not eloquently solve? To give you a better answer we need to know more about your problem domain.
Things to take into account when considering patterns/architecture: If you are building something with a Myspace type architecture you'll need a robust architecture (MVC). If you are creating a simple crud interface via the web - almost anything will do.
For .Net Web forms (I am assuming web, since you didn't say thick or web client) which is not MVC, it was a nightmare maintaining them. Web Forms applications that lived more that a couple years tended to become big balls of mud. Even then developers discovered ways to use MVC with web forms.
Ironically, the lack of MVC architecture in ASP.NET web forms was one of the driving complaints that lead to the development of ASP.Net MVC framework.
From experience if you don't use some MVCesk approach, your solutions become hard to maintain and bloated. These applications will die a slow painful death.
If your solutions are small one-off projects, the by all means throw something together. Heck there are tools that will generate everything from the screens to the data access layer. Whatever works to get the job done.
Classic CRUD apps built using tools like VB6 and Delphi have user interfaces, persistent storage and don't use MVC. Most of them used data aware controls linked directly to database fields
Couple of links comparing various MV* patterns which might be useful:WPF patterns : MVC, MVP or MVVM or…? & MVC, MVP and MVVM
Look into MVP model view presenter.
User interface is View and an application will always have a model and the bridge between the two is Controller. The whole MVC is nothing special as this is how the things will be always.
At the most you can get rid of Controller and have your view talk to your model but you loose the flexibility.
I've developed an alternative to ASP.NET MVC. You get the same loose coupling and separation of concerns but the difference is in how you go about building your projects.
I have a couple of videos on my blog, source code for the framework, a sample project and a few VS.NET add-ins (New Project item, New Builder and New View).
Builder for ASP.NET
Some key differentiating Features are
1. Templates are just html - no code mixed with templates
2. Templates are thus reusable across views and Web site designers can design templates in their design tool of choice
3. Strongly typed code (no ViewData and stuff) so you get intillisense, compile time checking, F12 navigation etc.
4. You build pages as compositions of views rather than an inside-out approach
5. View can be treated as "real" classes.
6. Everything is complied so no run-time compilation
Quite a few other differentiating factors as well.
In theory :
MVC is a proved technology and yada-yada-yada, and it is ideal for websites.
But in a real case:
A serious project that use MVC required a framework, hence you are following a framework with all their limiting and restrictions. So, at this point, the specific implementation of MVC is rule and not a simple "guideline".
Also MVC fail miserably for websites when it is about to connect to the model other than simple POST/GET, it fail with xml asynchronism and it fail with ajax. (*)
(*) exist some patch but a design must be clear and functional and if you need to "patch it" then it is neither clear nor functional.
Personally i think that the main problem with MVC is that it put so much effort in the Controller, where most project use not more that 5 lines for the controller part.
ps: Most "well done" MVC projects are 3-tier project.
ps2: MVC excluding some framework, is just a buzzterm, IS NOT A SERIOUS TERMINOLOGY and it is reflexed in the group of "interpretation of mvc".