Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm currently evaluating the programming model for creating future Webapplications in my company. So I will decide between ASP.NET MVC 5 (with Razor Views) and AngularJS with ASP.NET WebAPI. What are the advantages / disadvantages of these two programming models?
My 2 cents. I personally prefer pure HTML views, an entirely angular front end along with a Web API/EF/SQL Server back end, basically no Razor. Razor is an abstraction to help programmers render HTML, these days everyone's coming to the conclusion that removing these abstractions is a better idea, hence the evolution of ASP.NET from web forms, to MVC etc. It's not really difficult for developers to get to grips with HTML and use an angular front end, moreover this makes UI designers jobs easier, they have pure HTML and JSON/Javascript, they don't need to go about understanding MVC, Razor, controllers and actions. We used to work completely on MVC, in our latest project we moved to a Web API back end and an angular front end, and we've noticed that our UI designer's productivity has vastly improved.
I believe you cannot compare. AngularJS is a Single Page Application (SPA) framework whereas ASP.Net MVC use the standard model where one navigates between pages. Whether you want to build a SPA is decided by factors like
Do you want SEO. Which most of these JS rich framework have limited support.
How can you structure your app as SPA or multiple SPAs.
Coming from a type safe language C# to JavaScript programming is a challenge.
Learning AngularJS and using it effectively.
We use the standard MVC 5 razor view to setup the initial AngularJS views so you can even combine them together if required.
See this answer Can you use AngularJS with Parse.com? to derive more context.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have an web site built in ASP.NET. It is a business website that works with a lot of data.
I had a lot of problems, especially of speed and effectiveness, so I did what I can with ajax, and speed greatly improved.
I wonder if I should switch the web site to ASP.NET MVC?
I don't know ASP.NET MVC very deeply, so I want to know if I should invest in it, the main question is: Is ASP.NET MVC faster and more effective than regular ASP.NET?
I believe that ASP.NET MVC is (if not, already has) becoming the mainstream way to develop websites in using the ASP.NET stack. There is a lot less emphasis on ASP.NET WebForms in the last few years, which hints that MVC is the sensible choice for starting new projects (Note: WebForms is still a popular choice for some devs though, I'm not saying don't use it ever. There's still a place for it.)
Regards migrating existing ASP.NET WebForms apps, I would be a little cautious. Don't switch to another technology unless you have a very, very good reason for doing so. Depending of factors such as the amount of code, the design, it could take a lot of effort to convert an ASP.NET WebForms project to ASP.NET MVC.
In your situation you mention performance issues, which made you consider moving to ASP.NET MVC. I would look more into why your site is not performing as you would like. Use a profiler to measure which code paths are taking the longest ot execute. There are plenty of sites built using ASP.NET WebForms which perform to high-scale, so I would not make the mistake of moving to another technology in order to solve a performance problem.
It depends on where your current issues are.
Should you learn MVC - definitely.
Should you write new applications in MVC - sure.
Should you migrate old applications - depends.
What's the architecture of the current application?
How much time/resources do you have to allocate to a rewrite vs fire-fighting the existing app?
Is there a clear data or middle tier or is the data access built into each page code behind? Many applications are written so that the front-end can be swapped easily or called from other applications (eg via an API) but many webforms applications (not all) are written without these considerations and so it wouldn't be a swap out but a complete rewrite of the application.
What are the current issues other than "it's a bit slow"? For example I've seen an app that loaded the entire data model into memory for each page - simply changing the front-end would make no difference in this case as the cause of slowness was the data loading. Changing the architecture to load only what was needed significantly increased the speed.
The improvements you can get from using MVC aren't necessarily the business level ones you might expect. There are plenty of sites that go into this in more details, here's some to get you going:
MVC generates (much) cleaner HTML in the output - so pages are easier to develop/maintain and easier for developing UI interactions in javascript.
MVC has a much improved pipeline which can be hooked into, eg for adding action filters.
IoC/DI is hugely easier in MVC
Separates the model/controller code from the view html
Your application users won't care about any of these.
I have the same situation with one of my clients and after learning the MEAN stack and working with another company who made the transition to Nancy. I would recommend doing a REST API with Nancy and a pure front end with Angular or another Javascript front end. This will allow much faster response and flexibility down the road. Plus it will give you more flexibilty if you ever want to expose your API to other apps.
I tried to move from Web Forms to MVC and it was not very easy for me at the time.
You can use Asp.net Web Forms, with more ajax and less post backs and less view state usage if you do not want to move to asp.net mvc.
Asp.net MVC on other hand is very good with light wight pages and capabilities to blend in with client side ajax based solutions. And its architecture supports scale ability.
I think you should definitely take the time to learn MVC, as it is becoming a more marketable skill and future projects are more likely to call for it.
With respect to being faster and more effective, it is somewhat. First off, WebForms have a lot of overhead in order to have this windows-forms-like behavior (which, frankly, has never been a perfect fit for web pages). Second, MVC tends to render HTML that is much cleaner without the view state or long IDs. So those two items can make it faster. (Of course, if you are having speed issues you also need to look hard at your host server.)
With respect to rewriting your current project to use MVC, that's a more difficult question that only you can answer. WebForms still work and will probably be supported by Visual Studio for many years to come. Depending on your project, rewriting it can be a costly task. So you'll need to decide if it's worth it. That said, I hope to rewrite all my webforms websites using MVC as time allows, although part of the reason is just to update the look and make them more responsive to mobile devices.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have worked with window based application in .net. But I want to learn asp.net. So I want to develop one website such that developing that website I can get best and better knowledge of asp.net. And developing that website all most important concepts and controls are covered in that website. And in that website all the concept should be covered which are used in the website which are developed in today's time. So what should the website which I can develop to learn asp.net best and after developing that website I can have better knowledge of asp.net ? I have never develop a website. And which are the features that should be there in that website ? And that features are normally seen in today's website.And what are the books which I should refer ?
Update: Which are the other technologies I should also learn like javascript,css to develop better website of this time?
Make sure first which flavor of ASP.NET you want to learn:
ASP.NET webforms
ASP.NET Dynamic data
ASP.NET MVC
There are for the above mentioned technologies great tutorials which let you make up a complete site and in the mean time learn a ton from it to be found here http://www.asp.net/web-forms/fundamentals and Nerddinner.
Update: I forgot to mention the Music store sample.
Grz, Kris.
One possibility would be to pick a fairly simple database that you know well (such as Northwind or pubs) and make a web site for displaying and updating its data. This will get you familiar with data display controls such as GridView and DetailsView, and with ASP.NET databinding. You'll get to play with events and with the ASP.NET page life cycle. When you create a data entry form, you can learn ASP.NET's validators.
Once you've done that, you'll have a good foundation in ASP.NET. Most important, have fun!
Build your own blog.
Create a website that geeks from all over the world can use to meet for lunch. You could call it GeekLunch.com ;-)
I'd second XIII's answer on learning to distinguish between webforms and MVC, but if you're starting from scratch, it would be helpful to know the basics of both, to better decide which you like.
I prefer getting a big application and then reverse engineering, some prefer starting from scratch.
You already have Nerddinner for a sample MVC app.
Here are some sample webform apps:
http://forums.asp.net/default.aspx/2
They're a little dated, but the fundamentals are there.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I plan on building a simple, yet high usage webapp and need to settle on an architecture.
basic server side logic / dynamic db
driven content about half a dozen to
a dozen pages serving up all said
content
no need for URL rewriting,
pretty simple page flow/routing
The objective is to publish this app to use the least amount of bandwidth, memory, and CPU as possible. That said, my options are to
build in ASP.NET MVC
build in webforms with viewstate
disabled
build using .ashx handlers with code
that concatenates all HTML output
into strings that it spits out
Which is the most lightweight solution?
I appreciate the responses so far, but i'm not asking for the best solution. This is a simple app, and i want the solution that will use the fewest machine/network resources.
HttpHandlers are the most lightweight from your list of 3 options.
Personally, I would use ASP.NET MVC because it gives you a richer development environment with very little extra server overhead, especially if u turn most things off ..
eg. roles, etc.
Also use IIS7 intergrated mode and turn as much IIS7 settings off etc.
HttpHandlers are the most light weight, because the interface behind the ASHX file is IHttpHandler which is the basis of the Page object that is used both for Web Forms and MVC.
Omit the third option because it is very hard to control the application if it is all built using HttpHandlers.
basic server side logic / dynamic db
driven content about half a dozen to
One of the major benefits of ASP.NET MVC is the ease of the separation of concerns. +1
a dozen pages serving up all said
content no need for URL rewriting,
pretty simple page flow/routing
ASP.NET MVC will give you an easy interface to set your routes, a lightweight,clear, and controllable views. +1
WebForms are going to be the heaviest in most cases. ASP.Net MVC is quite lightweight and surprisingly fast compared to WebForms.
Building an application using HttpHandlers to serve pages may be fast when serving static content, but if you plan to use some sort of templating to serve dynamic data, you're going to cause yourself a lot of undue work. As for performance, it's hard to say with this option because your templating could be nasty or possibly not.
ASP.NET MVC, Web Forms and the Generic Handler (.ashx) are all HttpHandlers implementing the IHttpHandler interface.
Out of these options the Generic Handler (.ashx) would be the most lightweight.
ASp.NET MVC is as close as you can get to HtTP and Html.
You should use MVC, because you have a lot of more control about the generated client code than in WebForms, and is simpler than ashx handlers.
MVC very much gives you more control over HTML produced. So, from a bandwidth perspective, it definitely has better performance. With this may also come conciseness of code to generate this HTML.
However, MVC doe not improve business/data layer, or database performance, it just separates them. If you want to analyze, having multiple layers does not improve performance, just the structure of the program, which in turn may lend itself to methods for adding more performance.
A down side to MVC is learning how to think MVC and learning how to use the framework. If that is not an issue, go for MVC, it will teach you some good habits, if you don't have them already.
And finally, HTTP Handlers are not really meant for being used in this way, they are for things like file proxies.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
In response to an answer posted by Marc Gravell and his suggestion via email, I was wondering:
What choices do people make when deciding on their architecture for a new project?
This question could serve as a decent reference point for links/ideas/suggestions/architecture decisions, anything really that is of interest when deciding the best way to approach a new solution.
I am currently working on an ASP.NET MVC application - mainly as a exercise to increase my experience of the new framework - that works with an ExtJs front end passing Json objects between the layers.
Testability is very important so my .NET layer uses interfaces to define contracts and consists of a service layer, which handles data validation and application logic, which in turn interacts with a repository layer that just handles the data persistence and retrieval. All allowing me to test quite thoroughly.
I have a custom model hierarchy that is based on the database, however, it is not related to any ORM (I am using LinqToSql at present) tool tying it to a particular platform. My repositories return my custom models and not their own database structures, which will hopefully allow me to develop different repository implementations in the future without too many problems.
Another reason for this approach was that I am working with a legacy database that has some interesting design choices and cannot change the structure too much at present, so I wanted a bit more control over the resultant models.
All this may seem completely wrong to some of you so tell me what you think ;)
It sounds like you are on the right track. Personally, in the current incarnations, I would always choose MVC over web forms. Web forms abstracts too much from the underlying model and I find it is usually more trouble than it is worth. Only if you can safely predict that you can stick tight to the model web forms was designed to handle, work within the out-of-the-box pattern, and do not care much about testability, would I recommend web forms.
The only other scenario where web forms might make sense is if you have a team of people highly ingrained with this technology and want to keep inline with existing application stacks. Even then, for the growth of your developers and long-term product maintenance (post transition), I still recommend MVC if you can swing it.
That said, Microsoft will probably continue to support the web forms model for some time and eventually the two models will probably become easier and easier to plug and play or interchange with one another (based on conversations I have had with a couple of the ASP.NET team's program managers).
while enticing at first, for me, webforms become difficult to manage as the application grows. with mvc, relationships are more natural and consistent with ideals.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I would like to know your experience with ASP.NET webparts as a reusable component in your website.
How useful did you find it? Did you find any serious issues with it? Would you recommend it using in any asp.net project?
Any best practices or tips you would like to highlight with respect to this.
Would you recommend using webparts as part of the asp.net portal design or would our center your design around our good old UserControl as the foundation.
This input would help me make my decision for an asp.net application that I am developing.
In case you require more clarification please do leave comments.
Advantages of WebParts over UserControls:
Support for user editable properties and personalization built in
Customizable Editor Parts
Customizable standard WebPart menus
Drag'n'Drop WebParts between WebPartZones
Support for connections between WebParts, useful for master/detail views, filters, and more
Can load UserControls
Disadvantages:
Higher Resource Usage
Visual Studio currently does not have designer support for WebParts
Like ocdecio mentioned, ASP.NET MVC would probably be a better choice nowadays, at least outside of the SharePoint world, where WebParts are very important.
EDIT:
For an overview of ASP.NET 2.0 WebParts, you may want to look at:
Using WebParts in ASP.Net 2.0 and
Personalize Your Portal with User Controls and Custom Web Parts
I personally wouldn't recommend WebParts for your application unless you are going to go full-blown into the webparts portal paradigm. I played around with them sparingly and it just doesn't feel like it would be as effective as designing your own pieces.
In my experience web parts are useful to create content for SharePoint. But now with ASP.NET MVC I'm not sure they will be a good choice for a standard ASP.NET application.
I agree with TheTXI...like a lot of ASP.NET technologies, you aren't really going to get much benefit from Web Parts unless you buy into the model 100%.
But aside from that, we had some technical issues as well, mainly related to cross-browser UI rendering problems. These might have been fixed in recent releases, I don't know: we ended up rolling our own solution.
ASP.NET MVC is getting so much traction. It is literally blow everything else out of the water. I would recommend look into that first. Sharepoint probably will incorporate MVC very soon.