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.
Related
I want to create a largish ASP.NET MVC Web application. On some pages I would like to utilise AngularJS.
This app will not be a SPA.
At what point does this become a problem? For example at what point does running effectively two MVC paradigms become a headache?
Or is it a case of as long as you have clear delineation between what's using ASP.NET MVC (standard action methods etc) and what's using Angular JS then the two run side by side ok without giving you massive code organisation/maintainability headaches?
Cheers for any wisdom.
I'd love John Papas opinion!
Andrew
Since you are only asking for opinions, I will be happy to share my experience. The two do mix very well, and I think in most cases (at least most of my own development) the .NET side becomes very light weight.
Your .NET Web API Controller becomes a simple call to the Data Layer to populate a model or List(Of T) models. This gets returned as JSON to the Angular service.
From there, Angular takes over all of the logic until you need to perform another CRUD operation. Manipulating, validating, etc. all happens client-side in either the model (for me the Angular service acts as the model in MVVM) or the angular controller (which is really a ViewModel).
It's best if you let your model (Angular service) handle as much business logic as possible and restrict the Angular controller to responding to clicks, input controls, etc.
To sum up, let your .NET server side be very light. Just transport data back and forth to the Data Layer. Let Angular do the heavy lifting. You definitely do not need to be building a SPA to see the wonderful benefits of a JS data binding library, of which Angular is arguably the best of breed.
An excellent blog post that contains [ details of what I've discussed here ].
Good luck!
I use ASP.NET MVC alongside AngularJS for a fairly large in-house application. We don't really use many features of ASP.NET MVC beyond the basic page template and script bundling - so everything from the client-side is controlled by AngularJS and client-side routing - except for some distinctions we've made between 'modules' of the app where we wanted a different ng-app for each, along with different script dependencies.
If you're looking to take advantage of AngularJS on a page-by-page basis then I think you have no problem at all. As long as you reference the scripts (both core AngularJS scripts, and your AngularJS scripts for modules, controllers, etc.) correctly then you can just begin decorating elements with ng-app, ng-controller, etc. and it will just work. You could insert the relevant AngularJS scripts for relevant .cshtml pages using a #section declaration.
It will only be more complicated if you need a mix of server-side and client-side routing. Then it will be a case of carefully constructing ASP.NET MVC routes to deliver the SPA functionality where needed.
Is it possible to directly return a Classic ASP web page as an Action Result etc? I have just inherited a stack of Classic ASP applications that are still being maintained and even extended.
I am looking to stop writing new Classic ASP code move to an MVC based setup (as that is the direction the department is going). Therefore I am looking for any options that don't require me to rewrite all the applications but allow me to slowly add features written in ASP.Net.
Ideally I would like to organise features around controllers etc and then return existing ASP pages as the result of Actions. I'd like the URL structure to look the same as a normal MVC site.
Any thoughts or advice? I know there are other posts on this. Haven't seen any that are trying to return ASP pages via Action Result etc.
Thanks
Graeme
Is it possible to directly return a Classic ASP web page as an Action Result etc?
No. The best you could do is redirect. If you are migrating some legacy classic ASP site to ASP.NET MVC you could do it progressively. You can start replacing pages one by one by introducing controllers, models and views. iframes could also be used as a temporary solution to interoperate between the two technologies during the migration.
Ive been doing a bit of research / reading into mvc recently and was just wondering what the main purpose is.
is it as some people say to seperate the logic from the html
or to create clean url's
i could be missing the point completely, but asp.net forms really seperates the logic from the html and if you just want clean url's why not use a mod_rewrite rule?
MVC is a software engineering concept which is used more widely than just in ASP.net.
In a nutshell it encourages strong separation of:
business logic (the Model) the code which does all the brute force work behind the scenes; dealing with the database, performing large calculations; and
user interface logic (the View) the code which presents information to your users in a pretty way.
The C is for Controller - the ligaments that bind the bones of the model and the muscles of the views and allow them to communicate with each other cleanly.
You are correct that 'normal' ASP.net uses code-behind files so that page markup is kept separate from the code that generates that markup (in contrast to languages like PHP where code is embedded directly amongst HTML), but MVC ASP.net encourages even more separation in the ways I described above.
Take a look at this tutorial for a more detailed discussion of the pattern. Also take a look at this SO question
The MVC pattern has nothing to do with rewriting URLs. ASP.net MVC might make this easier but that is not by any means it's main purpose.
Testability is a big benefit of using ASP.NET MVC. It is non-trivial to write unit tests for ASP.NET winforms. It is much easier to unit tests for Controllers.
If you are doing MVC correctly, your views should be very light, and a lot of your logic is implemented in the Controllers.
Let me compare the two for you:
Asp.net web forms
They matured the old ASP technology that was much more like PHP. Code and presentation were piled up in the same file. Asp.net web forms upgraded this model by providing a mechanism of separating the two. But they built on top of the good things that windows application developers had. The drag drop interface creation with control events just like they exist in a windows application. Event thought code was separate from HTML, they were not separated. You still reference a lot of view controls in your codebehind, hence they're still very much bound to eachother.
Therefore it was rather easy to start developing on Asp.net web forms. But non savvy developers soon got to a bottleneck they didn't know existed (like slow postbacks due to huge view state etc.). Technology used some tricks to make this work. But on a serious large scale application this became quite a problem. Developers had to mingle their code to make it work with Asp.net web forms framework. Their complex forms had complex codebehinds with hard maintainable code with complex state.
The good (as well the bad) thing were at that time rich server controls. Nowadays with web 2.0 they don't seem rich anymore since they don't actually support client side functionality as much as they should. So Microsoft decided to also cram in something else. Update panels. That made partial rendering (and Ajax) possible with almost a flick of a finger. But it came with a cost. Everyone that used (uses) it soon realised it's not a viable solution that a professional application could implement.
Asp.net MVC
Now we have a new technology that doesn't have much in common with Asp.net web forms except for its first part of the name. MVC framework actually does separate code from user interface (view). Controller actions (code that executes on any HTTP request) is kept small and doesn't do anything with visualisation (it doesn't bind data to certain controls etc.). Controller action barely prepares data for the view to either consume or not. It's up to the view. Controller code doesn't in any way shape or form reference any view controls or anything. They're actually separate in MVC.
Views on the other hand just display and provide data. They can be partially or fully rendered. They support Ajax functionality to the point that everyone would like to use. Actually everything is separated into basic little things. Divide et impera (divide and conquer) seems to be the save-line here.
There's not hidden functionality. No flirting with windows development. It pure request response framework. Developer has the ability to 100% control the visual aspect of their app. But for the cost of not having rich controls out of the box. Those may be provided by the community or some developers prefer to create per purpose controls that serve the process much better.
Which one is better then?
Both have their pros and cons. But if you decide to build a semi complex, modern and maintainable application I'd suggest you give MVC a go.
But if all you need to do is a 15 screens application (without any particular interface requirements) it would be much faster to create it using Asp.net web forms.
MVC is a design pattern. Its purpose is to separate business logic and presentation details.
ASP.Net MVC is a mechanism to create web applications using ASP.Net and the MVC pattern.
One of the features of ASP.NET MVC is the ability to use SEO friendly URLs to provide commands to the controller part.
You can do as you have stated but ASP.Net have provided you a mechanism to do this easier.
The way ASP.Net Webforms was designed is that it made it easy for you drag controls on to the web form and code the logic underneath. ASP.Net MVC is designed so you separate your concerns easier.
The URL part of the ASP.NET MVC framework is just a modern phenomena to produce search engine friendly urls. They've infact been around long before the Microsoft team decided to add them to the framework (which required IIS7 before it could be done with no IIS extension).
The greatest pros in my view come from being able to test more easily, and separating off the parts of your application more cleanly. The whole ActionResult architecture of the ASP.NET MVC framework makes it very easy to switch from AJAX to plain out POSTs.
Delphi 5 use to employ the MVC model for its ISAPI extensions, 10 years ago.
MVC is not just an ASP.net thing, it is a design pattern that was widely accepted before it was created within the .NET framework, the thing about MVC is the separation of data from presentation(user interaction) from the business layer. It was just a way for Microsoft to offer that type of design pattern under the .NET framework
Although guys before me already give enough answers to the queston of purpose of ASP.NET MVC there is one thing I would like to add.
The ASP.NET Web Forms tried to abstract html and web from web development. That approach lead to the lacks in performances and usage of rich javascript frameworks.It was possible to create web application without actual knowledge of the web.
And to answer to you initial question, the purpose of ASP.NET MVC, I'll quote Dino Esposito:
With ASP.NET MVC, you rediscover the good old taste of the Web—stateless behavior, full control over every single bit of HTML, total script and CSS freedom.
MVC existed long before people tried to use it in HTML pages. The main reason for MVC is to get a grip on the logic to drive your application. MVC allows you to clearly separate things that should be separate: The model, code which converts the model value for the display and the code which controls the model.
So this is not related to HTML or URLs in any way. It's just that MVC makes it really simple to have clean HTML and simple URLs.
I'm a big fan of what ASP.NET MVC is doing, on many levels.
I'm about to take part in re-build of a very highly trafficked website, and I'm not which framework would be best (if any).
The site will need the following:
To support Javascript-heavy, highly interactive pages
But at the same time, provide underlying semantic HTML for search engines
Support multiple languages
Be skinnable
Expose a RESTful web-service API for partners
As far as I can tell, there's no reason not to use ASP.NET MVC for this.
I can present semantic HTML and layer Javascript on top using jQuery.
Multiple languages can be catered for using Resource files (same as at present).
Skinning can be done with CSS (it won't involve changes to the markup).
I can centralize business logic so that the Controllers and the WCF web-service use the same code.
But are there potential drawbacks to using MVC that I haven't considered?
I don't want to be the guy who picks a technology because it's cool but finds later down the track that it isn't very suitable for the job.
ASP.NET MVC is not good when all your doing is making a website that needs server-side code (but that's also true about ASP.NET also).
In your case I think MVC would be a great way to go. MVC has proven itself on high traffic websites (e.g. this one). However you must remember that MVC is new and changing. A library may not exists to do a specific task which means you'll have to write that code yourself.
Good luck on your rebuild!
You're good to go with MVC given what you've said about your project.
As far as I'm concerned, ASP.NET MVC is really only NOT good for situations where you have a large codebase in WebForms (meaning you have a lot of ASP.NET user controls, custom controls, etc). It's also not good if you are going to have people working on it who don't know what it's all about. Other than that, it's a pretty nice technology.
My two cents:
ASP.NET MVC is a great option but there is a little learning curve involved, so make sure your project plan/timeline has this handled. There might be developers on your team who might not be comfortable working with ASP.NET MVC, and this can cause possible delays (a lot of developers are still working in ASP.NET 1.1!).
#Alex: Lack of controls. Some features (like TreeView or Menu) are already implemented as Controls and it would be waste of time to reimplement them using mvc.
IMO the idea of using controls in ASP.NET MVC doesnt make much sense. You can create a treeview control using jQuery easily. Classic ASP.NET server controls carried a lot of baggage (viewstate etc) and hence ASP.NET MVC did not use any of those controls (though you can use helpers).
Finally, ASP.NET MVC is an alternative, not a replacement to Web Forms. I would not use ASP.NET MVC as it is still evolving, and my team is not very comfortable with it, but I guess slowly more and more programmers would shift to this (better) option.
I do not like ASP.NET MVC because of following reasons:
1.
Ugly routing API, there http://ayende.com/Blog/archive/2008/11/05/a-case-study-of-bad-api-design-asp.net-mvc-routing.aspx
is description of what is wrong.
By the way, friendly urls can be easily implemented without mvc
http://demo.liveui.net/bugtracker/Tasks/7
2.
Poor object model. It is proved that good software should consist of reusable components. There is nothing that can be reused in ASP.NET MVC based web site. For example, if you implemented smart drop down list once it will be difficult to use it again (even on the same web site).
3.
Lack of controls. Some features (like TreeView or Menu) are already implemented as Controls and it would be waste of time to reimplement them using mvc.
If I were you I would try to find some CMS and customize it for WebSite needs.
To responses:
YES. I know about ASP.NET controls disadvantages, but the question is about ASP.NET MVC. One can write a book about what is good and what is bad in ASP.NET but I do not think it is appropriate to discuss it here.
There are better ways of implementing MVC without using asp.net MVC. I have done it in the past, even before asp.net MVC came live. MVC is a pattern, not a technology, I do not understand why some people call it a Technology. You can separate all concerns by removing the code-behind from webforms and create your own controllers and routers and you will still have the advantage of the webform controls, etc to which most asp.net developers are used to use. asp.net mvc is nice for people whom do not really have the time to properly create an MVC app in a webforms environment and also to those whom do not have the time to architect a better solution. in conlcusion, asp.net mvc is good but there is a much better way of doing it and finally, MVC is NOT a technology.
This is a difficult question to ask because it's so wide ranging.
Does anybody know of a scoring system of questions that would aid in choosing between a WebForms and MVC application at the start of a project?
e.g. Is TDD an important part of this project? (If yes score 1 for MVC and 0 for WebForms)
I would consider the following:
Current Skill Set of the team. If you have a large team that aren't going to pick up MVC quickly but are comfortable with Web Forms I'd stick with Web Forms
What level of control do you need? MVC gives you more control but that also means you'll be doing a lot of extra things your self. WebForms gives you a lot less control but there are a lot more things in the box. If being able to control the HTML output is important to you than maybe MVC is a better fit.
Will you need third party integration? There isn't a whole lot of 3rd party control support for MVC however there is a ton of support for webforms. Getting a nice grid in webforms is simple, however you'll be writing a lot of your own code in MVC to solve that problem
As you mentioned, is TDD desirable?
State management is a lot easier in web forms
I have a single question test (disclaimer: it's far from perfect, but does the job a lot of time in making you lean toward each of the technologies):
Is your application more form oriented (e.g. intranet stuff or something) or you are building an Internet-facing Web site (e.g. StackOverflow). In the first case, I'd probably go with Web forms. The latter case is probably better satisfied by ASP.NET MVC.
Another thing: these two are not the only paradigms out there. Before MVC days, I've done several projects by building HTTP Handlers that do the routing and other stuff that MVC does. You could also strip the Web form part of ASP.NET and just use non-server-form Web controls (while you'd do it in a standard Web forms project, I can hardly call this style ASP.NET Web forms).
Unless you are working on a very data centric app and need server controls with databinding and viewstate, I would go with MVC.
I haven't made anything serious in web form since MVC preview 2. MVC is much better with regard to design patterns and best practices.
And yes IMO TDD is very important and gives more than 1 point to MVC.
Usually, the decision to use WebForms or MVC boils down to controls. If you are going to be using a lot of server-side controls, then WebForms is for you. If you don't have that burden then MVC, at least in my opinion, is much cleaner, and more testable.
After using both of them the way I decide now is: Do I need to use server controls? If I don't then I default to MVC.
If you were stuck with WebForms for some reason then you could implement the MVP (Model-View-Presenter) pattern to separate the view from the logic and have some hope of unit-testing the codebehind.