Currently we have a new menu item to our existing asp.net web forms application.
We have decided to go with MVC for this.
Please note that we have to share the same masterpages, css and Jquery files. We are currently planning to render the view inside a div in our aspx pages.
Is there a better way to accomplish this?
What are the limitations of our approach?
Can we leverage the MVC test cases in this approach?
Thanks
MVC is a stateless, disconnected architecture, you can not access the master page or aspx controls directly in the controller as aspx.cs does, secondly it is not possible to use the classic asp.net master page with mvc.
The things you can re use from existing project are:
UI Templates (design)
JS files
CSS files
Business Logic
Database
You can't use same master pages. You can't reuse ASP.NET MVC for some parts of your webforms view and vice versa. Either your view is completely on webforms or on ASP.NET MVC. And theoretically even mix of webforms with mvc in one web application could be problematic, but practically possible (see below point 1). So generally answer to your question is no.
If you are looking to ASP.NET MVC, you should think about step-by-step migration of your project to it.
Actually there are a couple of possibilities how to migrate
Mix in one project ASP.NET web forms and ASP.NET MVC. Technically it is possible. But it is some kind of hack. Your transition will be seamless but you can't your ASP.NET views. I will not recommend it. You can find this approach here http://www.devcurry.com/2013/05/adopting-aspnet-mvc-enhancements-in.html
In one solution use different projects for your webforms and mvc projects. In fact these are 2 different web application which typically could have common authentication, and there is question with webforms state. To solve problem with authentication you need create separate web service for it, which will be used by both. To solve problems with session state, use distributed caching for both, and try to change thinking from webforms state to caching, because mvc is actually stateless. Then for particular views you can redirect between views of both portals
I've spent the last couple months learning and developing a couple applications using MVC 4. I really like the simplicity of of the MVC model and the Razor View engine. However, now I'm now starting to hear more and more about Single Page Applications. Is this a case of SPAs being an improvement over MVC, and gradually replacing MVC? Or is this more a case of SPAs serving a particular type of application and MVC serving another?
SPA's are more suited to web applications such as Gmail rather than a typical website (by typical, i mean a site with normal text pages, some forms, and maybe even a shopping cart type thing).
I wouldn't go as far as to say SPA will replace MVC, but i believe they hold their own individually, but more importantly the SPA type frameworks like AngularJS, can also work together with MVC to create a more powerful website.
Microsoft recently released MVC 4 Beta, which has these new very nice features like Web API and SPA. And as always Microsoft's demos do not demonstrate best practices from software design prospective. For example, using DbController which is tightly coupled to EF.
It seems for me that SPA and Web API go hand-by-hand in modern ASP .NET app.
I would like to hear any suggestions about structuring MVC 4-based solution, which is going to apply these new technologies like Web API and SPA.
For example, is it a good practice to separate Web API project with it's own controllers out of base MVC4 project or not. How to deal with SPA and not to use DbController in order to keep data persistence separately? What's going to be a main role of regular MVC4 app and especially Razor views?
Any other thoughts or suggestions are highly appreciated.
On separation of MVC4 + Web API: imho (as always) it depends on your concrete project.
Regarding EF: you should definitely not return EF Entities but return your own DTOs instead.
The role of MVC razor views could be rendering partial views you dynamically load from the client. You also could do some stuff like conditional loading of CSS / JS etc. for the Index page being loaded initially.
I think it's a good idea to keep the API in a separate web site project from your SPA/web site, as you can run in to problems with greedy routes.
Definitely keep your data access separate and loosely coupled.
We have an intranet system developed using asp.net webforms. We are kind of planning to partly incorporate mvc and such a scenario is as follows,
We would like to generate html documents using mvc (using razor view engine) where the inputs are going to come from a normal asp.net webform (from a form button click or so)
Some pointers or references to tutorials on running these 2 scenarios side by side would help a lot.
ASP.Net MVC and WebForms postbacks don't mix; the only way to do this would be to use <iframe>s (which is not a good idea).
I am not sure about your described implementation... however, you could start by re-writing some of your aspx pages using MVC views and just get all the existing code behind into a controller to minimize the creation of new code. You could do this one page at a time until all of your pages are MVC views. Good luck.
When I first heard about StackOverflow, and heard that it was being built in ASP.Net MVC, I was a little confused. I thought ASP.Net was always an example of an MVC architecture. You have the .aspx page that provides the view, the .aspx.vb page that provides the controller, and you can create another class to be the model. The process for using MVC in ASP.Net is described in this Microsoft article.
So my question is. What Does ASP.Net MVC provide that you wouldn't be able to do with regular ASP.Net (even as far back as ASP.Net 1.1)? It is just fancy URLs? Is it just for bragging rights for MS to be able to compare themselves with new technologies like Ruby On Rails, and say, "We can do that too"? Is there something more that ASP.Net MVC actually provides, rather than a couple extra templates in the File->New menu?
I'm probably sounding really skeptical and negative right now, so I'll just stop. But I really want to know what ASP.Net MVC actually provides. Also, if anybody can tell me why it's Model-View-Controller and not in order of the layers of View-Controller-Model or Model-Control-View depending on whether you are going top to bottom, or vice versa, I'd really appreciate that too.
EDIT
Also, it's probably worth pointing out that I've never really cared for the web forms (AKA server controls) model either. I've only used it minimally, and never on the job.
.aspx doesn't fulfill the MVC pattern because the aspx page (the 'view') is called before the code behind (the 'controller').
This means that the controller has a 'hard dependency' on the view, which is very much against MVC principles.
One of the core benefits of MVC is that it allows you to test your controller (which contains a lot of logic) without instantiating a real view. You simply can't do this in the .aspx world.
Testing the controller all by itself is much faster than having to instantiate an entire asp.net pipeline (application, request, response, view state, session state etc).
Scott Guthrie explained it in this post "ASP.NET MVC Framework"
It enables clean separation of concerns, testability, and TDD by
default. All core contracts within
the MVC framework are interface based
and easily mockable (it includes
interface based
IHttpRequest/IHttpResponse
intrinsics). You can unit test the
application without having to run the
Controllers within an ASP.NET process
(making unit testing fast). You can
use any unit testing framework you
want to-do this testing (including
NUnit, MBUnit, MS Test, etc).
It is highly extensible and pluggable. Everything in the MVC
framework is designed so that it can
be easily replaced/customized (for
example: you can optionally plug-in
your own view engine, routing policy,
parameter serialization, etc). It
also supports using existing
dependency injection and IOC container
models (Windsor, Spring.Net,
NHibernate, etc).
It includes a very powerful URL mapping component that enables you to
build applications with clean URLs.
URLs do not need to have extensions
within them, and are designed to
easily support SEO and REST-friendly
naming patterns. For example, I could
easily map the /products/edit/4 URL to
the "Edit" action of the
ProductsController class in my project
above, or map the
/Blogs/scottgu/10-10-2007/SomeTopic/
URL to a "DisplayPost" action of a
BlogEngineController class.
The MVC framework supports using the existing ASP.NET .ASPX, .ASCX, and
.Master markup files as "view
templates" (meaning you can easily use
existing ASP.NET features like nested
master pages, <%= %> snippets,
declarative server controls,
templates, data-binding, localization,
etc). It does not, however, use the
existing post-back model for
interactions back to the server.
Instead, you'll route all end-user
interactions to a Controller class
instead - which helps ensure clean
separation of concerns and testability
(it also means no viewstate or page
lifecycle with MVC based views).
The ASP.NET MVC framework fully supports existing ASP.NET features
like forms/windows authentication, URL
authorization, membership/roles,
output and data caching,
session/profile state management,
health monitoring, configuration
system, the provider architecture,
etc.
Primarily, it makes it very easy to create testable websites with well defined separations of responsibility. Its also much easier to create valid XHTML UIs using the new MVC framework.
I've used the 2nd CTP (I think they're on five now) to start work on a website and, having created a few web applications before, I have to say its hundreds of times better than using the server control model.
Server controls are fine when you don't know what you're doing. As you start to learn about how web applications should function, you start fighting them. Eventually, you have to write your own to get past the shortcomings of current controls. Its at this point where the MVC starts to shine. And that's not even considering the testability of your website...
No more auto-generated html IDs!!! Anyone doing any sort of javascript appreciates this fact.
ASP.Net with it's code behind is almost MVC - but not - the one big thing that makes it not is that the codebehinds are tied directly to the aspx's - which is a big component of MVC. If you are thinking of the codebehinds as the controller - the should be completely decoupled from the view. The new .NET MVC rounds this out - and brings a complete MVC framework. Though there are existing ones for .NET already (see Spring.NET).
I looked through a couple simple examples such as this one. I can kind of see the difference. However, I don't really see how MVC uncouples the view from the controller. The view still references stuff that's in the controller. I do see how it makes it much easier to test, and that at least in MVC the controller doesn't have any knowledge of the view. And you wouldn't have to process the view to call methods in the controller. I can see that's quite a leap, even though at first glance it may not seem like much.
I do agree with #Will about fighting server controls. I've never worked in a situation where they were actually used, but many people I know who have, have run into quite a few limitations with them.
Article about ASP.net MVC Vs ASP.net Web form
http://weblogs.asp.net/shijuvarghese/archive/2008/07/09/asp-net-mvc-vs-asp-net-web-form.aspx