Last evening i was thinking that there are different view-engines in asp.net mvc like;
Spark
Web Forms
Razor
(i know the are differed syntactically as well but)
Do they effect the perfomance of asp.net mvc projects?
Let's say i would like to use "Razor" instead of Web Froms. So, will i get the performance hit? if yes. Please! explain.
Thanks in advance!
Yes, every choice you make in software development will impact performance. However, many choices don't make a noticeable difference.
Do you have a performance problem in your MVC app? Unless you can pinpoint Razor as the performance bottleneck, which is unlikely, don't bother.
Most performance issues in a web application are related to database queries, general network traffic, uncompressed static resources, etc.
Depending on your usage of each listed view engines (Spark, Web Forms, Razor) you may get potential performance problems.
Unfortunately, great tool ended to be not properly used, eventually turns to be a problem.
All in all, i will suggest to use the view engine that you and your team feel more comfortable with.
Basically, trying to be aware of options and mastering your tool base is the way for productivity and good performance.
Related
I'd like some vague guidelines about the relative effort to build using ASP.NET versus Silverlight/WPF. I know, it all depends, but any input greatly appreciated.
I'm rebuilding a winforms app and planning on moving it to either:
ASP.NET (could be MVC or webforms), or
Silverlight (4) or WPF with ClickOnce deployment.
It's a typical business-style app with some tens of forms, various datagrids, standard windows controls, etc. Some chart graphics but no multimedia. It's not very data-heavy, i.e. there are quite a few datagrids but they'd seldom have more than 10 cols & 100 rows and usually less. The logic is currently tightly coupled with the winforms code so either way it'll need to be split out from the UI. We also use Crystal Reports for reporting.
The 2-3 developers who will be working on this have some WPF & ASP.NET experience but not much.
I'm tempted to use Telerik controls or similar as they look like they make some things we want to do easier.
The app is installed for a customer and only used internally within their firewall. The main advantage to ASP.NET would be deployment, but I figure that silverlight or wpf with clickonce wouldn't be much worse for deployment and may be faster to build.
If there's any other general information I can provide which will make it easier to estimate relative effort, let me know!
thanks.
UPDATE:
Let's assume the only basis for my decision is the speed/productivity of development (i.e. ignore deployment, UI impact, etc). Which should I choose?
What you use and how cost effective the project will be totally depends on requirements and your team's skill sets. Learning ASP.NET (MVC or WebForms) is typically a long, hard road if you come from a WinForms background (and arguably, if you are doing WebForms, you may as well so Silverlight). If you have a lot of experience with HTML/CSS/JavaScript(jQuery)/MVC patterns, then ASP.NET MVC will probably suit your project better. If you have requirements such as cross-browser compatability, SEO or other weby things, you'll probably go ASP.NET MVC.
On a recent project, where we had an assessment of the requirements and available technology options, we were forced down the ASP.NET MVC by the client but we had determined that given the team and requirements, Silverlight would have been an easier (read: less expensive) technology to implement the application in and it would have reduced the project cost by 50%. (educated, thumb in air guess)
In my experience, the biggest delays are caused by "black holes" - things that you'd assumed were going to be easy when you put together your estimates, which turn out to be hard/complicated/time-consuming due to leaky abstractions, framework bugs, and so on.
I'd therefore favour an approach which uses proven technology and protocols and minimal abstraction, and for me, that would be ASP.NET MVC. But make sure your developers understand HTTP, HTML, the model-view-controller pattern and the fundamentals of stateless architecture.
I watched a little introduction into ASP.NET Dynamic Data, and I noticed this option to create a data driven website for the first time. I have a database with a few tables, just created a Dynamic Data application out of my database and well... my application with a lot of nicely looking web pages, navigation between them and all kinds of CRUD operations was finished after 3 minutes.
OK, seriously, it isn't finished of course. There is a lot of custom logic to introduce, design to change, and also pages or relationships to remove I don't want actually to see in the web application.
But now I am wondering if ASP.NET Dynamic Data is at least a viable starting point or do I better start from scratch and create page by page? I could imagine that it might be useful to create a quick database maintenance web interface but is it good for a very customized web application? Is it in the end more complicated to modify the scaffold than building up everything from the ground?
I'm very interested in your experiences or recommendations regarding Dynamic Data! Thanks in advance!
I could never wrap my ahead around it enough to get any use out of it. At first, I thought this was Microsoft's answer to Ruby on Rails, and I was looking for the same benefit. I don't it comes close to having the same benefits. When I then compare it to a CMS (DotNetNuke, Sharepoint, Drupal, etc) it then looks really underpowered. Compared to ASP.NET MVC, it seems like going the wrong way from basic ASP.NET (MVC is removing bad abstractions from ASP.NET, while DD is adding even more abstractions).
Personally I'd rather build something from scratch in ASP.NET MVC, though my day job is regular ASP.NET. I'm also learning Drupal as I haven't found the sweet spot with ASP.NET based CMSes. One thing at at a jobsite you're going to want to use technologies everyone else knows. So I think that limits where knowing Dynamic Data is generally useful, as basically any legacy application won't be using it and you're unlikely to find a team with existing ASP.NET Dynamic Data experience.
The quick scaffolding is spiffy but at the end of the day I don't think it will make web development easier.
I very like ASP.NET Dynamic Data as it is a fast way for creating data driven applications. Customization is not a complicated task.
I wrote a corporate website with this technology from the scratch - it takes appr. 2 months for all. So my point of view that this is a good starting point for web applications development.
if your archetecture resembles ASP.NET Dynamic Data or DotNetNuke or some other starter kit, go for it, if
application is small to medium sized
you do not have strict deadlines
you are learning the technology.
otherwise or when you will be skilled in particular technology, you will prefer yourself working from scratch as it gives you more freedom and space for the implementation of ideas.
For e.g, one reason for the breakthrough for Asp.Net MVC had was many .Net developers wanted freedom over the development / architecture / flow and rendering (HTML) of the product they were building. Asp.Net WebForms does provide solid and vast grounds for swift development and templates but developers had to go according to the architecture. This freedom is available under MVC and developers can make use of nearly all Libraries and skill set available and go their own way.
one successful sample is Stackoverflow.com itself
hope this helps
I have a portfolio made in C#/ASP.NET which started off small but, as it is selling myself, it has grown in size very quickly.
I started off with using ASP.NET webforms model but this has meant that some of my code is in class libraries (.dlls) and some in page codebehind.
I want to fix this (no defined stucture), but without the overhead of migrating to ASP.NET MVC or WCSF.
How could I address these problems? I am thinking of moving all logic to WCF services and calling them from page codebehind. Is there a better way?
EDIT: The current problem is codebehind (used only as the site was small at the start but now it gets a lot of attention from me with updates). I want to seperate this all out so it's easy to test (what MVC addresses), and the coupling is generally low. Is it enough to use WCF to achieve this? What other techniques could I employ? Maintainability is another concern because maintaining a codebase split between .dlls is awkward (when debugging, as I noticed and mentioned in some previous threads).
Thanks
Unfortunately, traditional web forms applications are damn near impossible to test. WCF won't be of much help because it's a communications technology that will help you to get the data to codebehind classes but won't help you to render or test pages.
Due to this complexity, there are very few test automation tools, and the few there are are commercial paid-for products. One such tool I have heard of, but have not used personally, is Ivonna. You can also test using browser automation. Two great tools to help with this purpose are watin and WebAii.
This is, of course, dependent on whether you still want to keep the original code lying around. What I take in when I read your post is that you want all of the benefits of MVC. Unfortunately, it may be best to take the plunge and rewrite the application. It's painful, I know, but the sheer amount of hackery to make WebForms ape MVC concepts is overwhelming, to say the least.
I cant fully imagine what you need, but consider URL redirection / slug
My team is considering building our next web app using the ASP.NET MVC framework. I am slightly hesitant, as are some others, because it is still only in beta. I really want to dive in because it seems to be a great way of providing clear separation of concerns and improving testability.
Should I take the plunge now, while MVC is still in beta, or hold off for a release candidate?
From some of the responses, I think I need to clarify my question a bit. My primary concern is whether to go with a product that's still in beta, not webforms vs. mvc. The concern is mainly because of the fear that we end up using some functionality in the beta version that gets changed / deprecated / not supported in the final release.
However, I do appreciate the perspective on webforms vs. mvc. It just doesn't get at the heart of my question.
It's a pretty simple decision tree, really.
Choose ASP.NET MVC if you...
Care deeply about URLs
Care deeply about your HTML
Want true separation of concerns
Want testability through and through
Want flexibility of view engines (ASPX, NVelocity, NHaml, etc)
Choose WebForms if you...
Enjoy the stateful abstraction of WebForms (ViewState)
Don't mind PostBack model
Prefer components that you can "drag & drop" on a page
For me, the answer will 99% be ASP.NET MVC, because I think it is a much better match for the web. I think the ajax story is much cleaner as well, and I have complete control over my HTML & URLs. On top of all of that, I can test-drive my website (controllers) quite easily.
Yes, I know you can achieve clean URLs in WebForms, and you can have clean(er) HTML through Control Adapters, and you can achieve a level of testability with the MVP pattern in WebForms, but these are all off-the-beaten path approaches. With ASP.NET MVC this stuff is core. That's just the way you do it.
And don't worry about the preview/beta status. The team has always maintained that you don't need a go-live license to deploy it (even though they now offer one). It's purely additive on the existing ASP.NET Runtime.
It's like automatic vs. manual transmission. Pick one that makes you happy and run with it.
I prefer ASP.NET MVC to WebForms, so I would choose that, but you need to work out as a team where your core skill set is and whether or not choosing MVC will:
Create a better product.
Get you to market quicker.
Don't just choose it because it's new. WebForms is still a great choice, and you can write code for WebForms that's both testable and has clear seperation of concerns.
So far Mvc looks good, however I m a castle advocate I have used monorail in many production sites and it got me into learning about IoC and AR
Cheack out castleproject.org
I'd recommend giving it a shot.
We just recently released an e-commerce platform with MVC running the front end, and while there are some gotchas that you may stumble upon (Say, resolving Url's with anonymous types is currently far slower than using a RouteValueDictionary, was a surprise to me), it certainly feels like it was a lot easier to build a manageable system in MVC compared to our older WebForms apps.
If you have the luxury of choosing, then you should definitely have a closer look. The bugs that have shown up while we worked on it have all been fixed fairly promptly, and most things work well now, and it's starting to feel pretty complete.
But in the end, it's always a risk to take on an early beta product. :)
Unless your app is super simple, it's likely that MVC will be released before you go to production. That hardly matters though. I have been building on MVC since Preview 2. Each new version has contained breaking changes; however, they have not been very hard to track down and fix. It's very unlikely that by 1.0 you could create a mountain of code that would be toppled over by some breaking changes. Simply budget a few person hours to apply each new version.
If you don't have to put your app in production soon, yes write it in MVC.
Here, we have a team working with MVC and planning to put it on prodution at jan/2009.
If it's not mission critical and you and your team have the time to learn it, why not?
I found some wild remarks that ASP.NET MVC is 30x faster than ASP.NET WebForms. What real performance difference is there, has this been measured and what are the performance benefits.
This is to help me consider moving from ASP.NET WebForms to ASP.NET MVC.
We haven't performed the type of scalability and perf tests necessary to come up with any conclusions. I think ScottGu may have been discussing potential perf targets. As we move towards Beta and RTM, we will internally be doing more perf testing. However, I'm not sure what our policy is on publishing results of perf tests.
In any case, any such tests really need to consider real world applications...
I think this will be a hard question to definitively answer as so much will depend on A) how you implement the WebForms application, and B) how you implement the MVC application. In their "raw" forms, MVC is likely faster than WebForms, but years and years of tools and experience have produced a number of techniques for building fast WebForms applications. I'd be willing to bet that a senior ASP.NET developer could produce a WebForms application that rivals the speed of any MVC application- or at least achieve a negligible difference.
The real difference- as #tvanfosson suggested- is in testability and clean SoC. If improving performance is your chief concern, I don't think it's a great reason to jump ship on WebForms and start re-building in MVC. Not at least until you've tried the available techniques for optimizing WebForms.
It decreased one of my pages from 2MB payload, to 200k, just by eliminating the viewstate and making it bearable programatically to work with the submitted output.
The size alone, even though the processing was the same will create vast improvements in connections per second and speed of the requests.
I think that many of the people who think that WebForms are inherently slow or resource intensive are placing the blame in the wrong place. 9 times out of 10 when I am brought in to optimize a webforms app there are way too many places where the apps authors misunderstand the purpose of the viewstate. I'm not saying that the viewstate is perfect or anything, but it is WAY too easy to abuse it, and it is this abuse that is causing the bloated viewstate field.
This article was invalueable in helping me understand many of these abuses. https://weblogs.asp.net/infinitiesloop/truly-understanding-viewstate
In order to make a valid comparison between MVC and WebForms we need to be sure that both apps are using the architectures correctly.
My testing shows something between 2x and 7x more req/sec on MVC, but it depends how you build your webforms app. With just "hello world" text on it, without any server side control, mvc is around 30-50% faster.
For me the real "performance" improvement in MVC is the increase the testable surface of the application. With WebForms there was a lot of the application that was hard to test. With MVC the amount of code that becomes testable basically doubles. Basically all that isn't easily testable is the code that generates the layout. All of your business logic and data access logic -- including the logic that populates the actual data used in the view -- is now amenable to testing. While I expect it to be more performant as well -- the page life cycle is greatly simplified and more more amenable to web programming -- even if it were the same or a little slower it would be worth switching to from a quality perspective.
I think the problem here is that no matter how much faster ASP.Net MVC is than the old webforms, it won't make a difference, because most of the time taken is in the database. Most of the time, you web servers will be sitting at 0-10% CPU usage just waiting on your database server. Unless you get an extremely large number of hits on your website, and your database is extremely fast, you probably won't notice a big difference.
The only concrete numbers I can find which are from early ASP.NET MVC-development is on this forum-thread:
http://forums.asp.net/p/1231621/2224136.aspx
Rob Connery himself somewhat confirms statement that ScottGu has claimed that ASP.NET MVC can serve 8000 requests per second.
Maybe Jeff and his crew can give some kind of hint from their development of this site.
Contrary to the accepted opinion, optimized webforms usage completely kills MVC in terms of raw performance. Webforms has been hyper-optimized for the task of serving html far longer than MVC has.
Metrics are available on http://www.techempower.com/benchmarks/#section=data-r7&hw=i7&test=db
Every single comparison mvc is on the lower-middle/lower-upper rankings of the list, while optimized webforms usage places in the upper-middle/upper-lower rankings.
Anecdotal but very serious validation to these metrics, www.microsoft.com is served by webforms not MVC. Does anyone here believe that they wouldn't have chosen MVC if it was empirically faster?
There's really no way to answer this. MVC uses the Web Forms view engine by default itself, and can be configured to use any number of custom view engines, so if you want a performance comparison you'll have to be more specific.
I started out work in MVC about a year ago, I was inspired but not impressed.
I loath the view state and see it as the root of all evil in terms of ASP.NET. This is why I just don't use it and to be perfectly honest why would you?
I took basically the ASP.NET MVC Framework concept and built that in my own way. I changed a couple of things though. I built my controller wrapping code, or URL routing code around dynamic recompilation.
Now, I would go as far as to say that ASP.NET MVC applications will be faster based on how you use it. If you completely abandon WebForms you'll be faster becuase the ASP.NET life-cycle and object model is humongous.
When you're writing you're instantiating an army... no wait, a legion of objects that will participate in the rendering of your view. This is gonna be slower than if you where to express the minimal amount of behavior in the ASPX page itself. (I don't care about view engine abstraction because the support for ASPX pages in Visual Studio is decent, but I've completely dropped WebForms as a concept and basically any ASP.NET framework due to code bloat or not being able to change the things that wire my application).
I've found ways of relying on dynamic recompilation (System.Reflection.Emit) for emitting special purpose objects and code whenever needed. The executing of this code is faster than reflection but initially built through the reflection service. This has given my MVC flavored framework great performance but also very statically typed. I don't use strings and name/value pair collections. Instead my custom compiler services goes in a rewrites a form post to a controller action being passed an reference type. Behind the scene there is a lot of things going on but this code is fast, a lot faster than WebForms or the MVC Framework.
Also, I don't write URLs, I write lambda expressions that get translated into URLs that later tell which controller action to invoke. This isn't particularly fast but it beats having broken URLs. It's like if you had statically typed resources as well as statically typed objects. A statically typed web application? That is what I want!
I would encourage more people to try this out.
The projects created with visual studio. One is mvc4 template, another is WebForm (tranditional).
And when make load test with WCAT, this is the result,
MVC4 is quite slow than WebForms, any ideas?
MVC4
could get about 11 rps
rps is quite low both 2-cpu or 4-cpu server
WebForms (aspx)
could get above 2500 rps
the performance killer has been found that it's a bug of MVC Bata or RC.
And The performance would be improved once i remove Bundles things. Now the latest version fixed this.
Performance depends on what you are doing... Usually MVC is faster than asp.net mostly because Viewstate is absent and because MVC works more with Callback than Postback by default.
If you optimize your webform page you can have the same performance as MVC but it will be a lot of work.
Also, their is a lot of nugets for MVC (and also for Webform) to help you to improve website performance like combine and minify your css and javascripts, group your images and use them as a sprite, and so on.
Website's performance depend greatly of your architecture. A clean one with good separation of concern will bring you a more clean code and a better idea of how improve performance.
You can take a look at this template "Neos-SDI MVC Template" which will create for you a clean architecture with lots of performance improvements by default (check MvcTemplate website).
I did a small VSTS load test experiment with some basic code and found ASP.NET MVC response time to be twice faster as compared to ASP.NET Webforms. Above is the attached graph with the plot.
You can read this load test experiment in details from this CP article https://www.codeproject.com/Articles/864950/ASP-NET-MVC-vs-ASP-NET-WebForm-performance-compari
Test was conducted with the below specifications using VSTS and telerik load test software:-
User load 25 users.
Run duration of test was 10 minutes.
Machine config DELL 8 GB Ram, Core i3
Project was hosted in IIS 8.
Project was created using MVC 5.
Network LAN connection was assumed. So this test does not account for network lag for now.
Browser in the test selected Chrome and Internet explorer.
Multiple reading where taken during the test to average unknown events. 7 readings where taken and all readings are published in this article as reading 1 , 2 and so on.