I recently came across this article about how Myspace handled scalability issues and at one point adopted ASP .Net framework which resulted in improvements in the site's performance. Pardon my ignorance, this came as a surprise to me because I never knew about ASP .Net being used in such big websites which routinely face heavy traffic and handle huge computation.
My Questions are, Is ASP .Net a good framework to use for such websites? Which other popular sites use ASP .Net framework?
This site was built in ASP.NET C#, for example. :)
The .NET framework is just as capable as any other framework. How well a site performs really depends on the developers putting it together.
I believe MySpace was first built with Cold Fusion, which is notoriously slow. I'm not surprised that they experienced performance gains after switching to .NET.
There are plenty. A good example is this very site you're on.
Of course, it's also up to how you design your site. No platform will make up for a bad design, but there's absolutely no reason why ASP.NET can't scale properly.
When it comes to that scale, it's mostly depending on infrastructure and a scaleable architecture. The major difference I think, and I say it from experience, if running in a windows environment, it often takes a "few" machines more than it would take if you we're running i.e. *nix. But hey, theres always Mono!
Quoted High Scalability:
"Their system had " “hundreds of hacks to make it scale that no one wants to touch," which hamstrung their ability to really compete."
And:
"Because of their infrastructure MySpace can’t change their technology to make new features work or make dramatically new experiences."
http://highscalability.com/blog/2011/3/25/did-the-microsoft-stack-kill-myspace.html
Related
I'm relatively new to programming and I have some questions. I'm currently simultaneously trying to learn ASP.NET MVC from the official Microsoft book because I'm looking to get the certification in a few months and at the same time working on a small project for a colleague. Instead of doing things with .net framework i decided to just do everything in .net core and there are some discrepancies between what I learned in the book and what seems to be available in EF Core.
I'm using Sqlite for my database and I've already plugged that in for the most part but I'm running into some issues where various people on the internet are providing me with conflicting information.
So in the .net framework version of ASP.NET, the way Microsoft said you should do things is, You have a Model PersonModel and a context PersonContext that goes in the Model file and inherits DbContext. This PersonContext contains various DbSet<T> objects depending on which tables you want to make etc. This has remained the same for me in .net core. However after this Microsoft tells me to make a PersonInitializer which is supposed to inherit DropCreateDatabaseAlways<PersonContext> and then override the Seed method (conveniently thats also where a getFileBytes method is placed for images etc).
Now, in core, there is no DropCreateDatabaseAlways class to inherit, leading me to believe this structure is actually not intended at all by .net core. I've heard various things on here about using various CLI commands but in the end I'm basically just very confused about what the "proper" thing to do is here?
It think your largest problem at this point is just sourcing information properly. Admittedly, it's a bit confusing, especially for someone completely new on the scene.
A little background to start: there's ASP.NET, ASP.NET MVC, and ASP.NET Core. ASP.NET is really nothing, although it became short hand for ASP.NET Web Forms, as that was the only thing you had to work with at the time. Then, Microsoft introduced ASP.NET MVC, which took the foundation of ASP.NET and layered on an attempt at a modern web application framework modeled after the MVC (model-view-controller) pattern. It was a vast improvement over Web Forms, but did not fundamentally break away from the older system enough to make it a truly great application development framework. Because of it's reliance on System.Web (a monolithic family of DLLs) and the full .NET Framework, it was slow, hard to deploy and completely incompatible with things like containerization. Enter ASP.NET Core, which was a complete rewrite from the ground up.
ASP.NET MVC had a sister framework in ASP.NET Web Api, and technically you could still employ ASP.NET Web Forms in the same project. In fact, a single project could utilize all three frameworks at once, which is as convoluted as it sounds. ASP.NET Core, at least initially, did away with this confusion by just having a single system for both traditional web applications and APIs. As such, if you're looking for information about Core, it's just "Core". Looking for ASP.NET Core MVC is just going to lead you to outdated information.
That said, frustratingly, Microsoft decided in their infinite wisdom that Web Forms, though reviled by most every developer who had ever used a real web application framework, were actually so awesome that they should be resurrected, at least in spirit. Thus was born Razor Pages, and ever since it's been necessary to make a distinction between ASP.NET Core Razor Pages and ASP.NET Core Proper, which has now been relabeled as ASP.NET Core MVC, making it that much more difficult for people to filter out information on one framework versus another. At least for the time being, Razor Pages are still not as prominent as the MVC-style, and thankfully, they at least don't change much in the core functionality of Core to warrant differing discussions on most things. Long and short, you should pretty much just prefix every search with "asp.net core" (in quotes, so it's done as a phrase search). That will generally always give you relevant information - for the most part.
The next set of issues is that ASP.NET Core was developed with high visibility, fully out in the open and with many, many previews, alphas, betas, and even full releases. On the one hand, that's great and is a large part of why it's as good as it is. Developers were able to provide input and steer the development, making it the first web application framework developed by Microsoft actually designed by and for the people actually in the trenches, building web applications.
The downside, though, is that things changed - a lot - and still do. Though, it now seems to be leveling off pretty well after 2.1, which I consider to be pretty much the first truly feature complete release. However, before we got here, we had ASP.NET vNext, ASP.NET MVC 6, DNX, and then ASP.NET Core 1.0, 1.1, 2.0, and finally 2.1 - all of which fundamentally changed at least how some things work. In other words, even if you confine your searches to ASP.NET Core, there's still a lot of outdated and incorrect information out there, simply because it was written about a previous version and things have changed since. To better your odds, you should consider confining your search to things published within the last year (2018+, 2017 if you can't find anything newer). Any older than that, and you're going to have to take the article with a big, huge grain of salt.
And then that brings us to Entity Framework. Oh my. EF has had a storied history, most of it steeped in failure. The original EF wasn't even viable until version 3. The previous versions were so bad they were literally unusable for any serious production work. Even then, it wasn't until EF 4 that it could really even be consider truly ready for prime time, and finally began having some significant uptake among developers as a result. It was also the release where Code First was finally introduced (technically in 4.1).
Before that time there was what the EF team referred to as Database First or Model First. The only meaningful difference was that one would generate your models from an existing database, while the other would let you design your models and then generate a database from that. In either case, you ended up with a monstrosity called EDMX, an XML beast that attempted to keep up with your database state and all the translation of VB/C# classes to that entails. It was an absolutely nightmare to maintain, almost never worked correctly, and a constant source of frustration.
Code First provided an alternative - a shining light in the darkened pit of EDMX hell. You could use POCOs (plain old class objects) and EF would be able to generate migrations from changes you made to those to update your database accordingly. It could even be used to work with existing databases, though it's name prevented it from being used as much as it should have been in that area (many people wrongly believe that if you had an existing database, you had to continue using the old horrible Database First methodology). In truth, Code First was a complete alternative approach to managing databases, both new and existing. EF 5 and EF 6 continued to refine this new approach, and when it came time to work on EF 7, Microsoft decided it was high time EDMX went to its well-deserved grave.
However, work on EF 7 coincided with the development of ASP.NET Core, which itself spawned off .NET Core and eventually .NET Standard. EF was firmly rooted on the full .NET Framework, so it became apparent that a rewrite was in order. As such, development of EF 7 was cancelled, and EF Core was born. EF Core, though, had a rough ride. ASP.NET Core was moving along like a freight-train, but had no native way to interact with databases. You could use old EF, but then you were forced to target the full .NET Framework, instead of .NET Core. As such, EF Core was rushed to release way too soon, and 1.0 was a train-wreck of epic proportions. There was so much basic functionality missing and the workarounds were so obtuse that virtually no one in their right mind actually would take anything into production with it. Then, 1.1 was release and things improved somewhat but still not enough. Then came 2.0, and finally, it was workable ORM, you could actually feel comfortable using in production. The release of 2.1 has brought even more improvements and refinements.
Now that you've had your history lesson, all I can say is that finding good documentation is still unfortunately a bit of a crap-shoot. You need to be very specific with your searches, using the right terms (which is part of why I wanted to give you the history). You also need to pay close attention to dates. Consider suspect anything that existed before 2017 and treat even stuff from that year with a grain of salt. The official docs are your best friend. Microsoft has actually done a pretty fantastic job with their documentation and keeping it up to date and accurate. It covers the largest majority of things is the ultimate source of truth.
Official ASP.NET Core Docs
Official EF Core Docs
Books are not going to be your friend here. The publication process takes far too long and ASP.NET Core has moved far too fast. Any book on Core is outdated the minute it hits the streets. However, if you have a subscription to Safari Books, you might have luck due to their prelease and alpha offerings there. You have to deal with more technical mistakes, grammatical errors, etc., but at least the information will be closer to the actual truth.
Pluralsight has some truly excellent videos that can help you. Unfortunately, video production has a similar problem as book publication, and there's more than few courses that are now so outdated as to be useless.
Hope this at least gives you some better context and helps improve your ability to source good and accurate information. Honestly, I still struggle myself with that a lot of times, and I think most developers working in this space has the same issue. It's fun and exciting, but it's not without its cons. Having to wade through a sea of information to find some pearls is one of them. Good luck.
I'm looking to upgrade my ASP.NET web app to the .NET 4 framework. Would I see performance improvements right away?
According to this blog post, there are supposed to be internal runtime improvements that should help out of the box.
According to Microsoft, there have
also been a number of invisible
performance improvements in the
internals of the ASP.NET runtime that
should make ASP.NET 4.0 applications
run more efficiently and use less
resources. These features come without
any change requirements in
applications and are virtually
transparent, except that you get the
benefits by updating to ASP.NET 4.0.
There is a PDC presentation (which I cannot currently find) that claimed the same thing. I would assume that YMMV depending on your implementation, in any case.
Obviously ASP.Net 4.0 will benefit from any areas of the .Net 4.0 runtime on which it depends that are improved. It's usually safe to assume that a new release will make things no worse...
A lot of the performance improvement is probably in development. A lot of things have been improved like handling of ID's so Javascript can interact better with controls. And some C#4.0 features like the dynamic object and it late binding. Here is a list of all the benefits ASP.NET 4.0 Have:
http://www.asp.net/learn/whitepapers/aspnet4
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Why should I upgrade to c# 4.0?
Our projects are currently all C# 3. If we dont have a specific requirement for features that C# 4 provides, would there be any other reasons for us to upgrade? Thanks.
Edit
There seems to be more of an advantage with using the new CLR and not just the new language features.
I personally don't feel that there are great language enhancements between C#3 and C#4 if you're targeting the same framework (2.0-3.5).
However, if you move to .NET 4 CLR as well, I think there are all sorts of benefits in the runtime you can take advantage of. My favorite feature is the parallel task library.
It depends on what you want to do. I don't there are killer language features that 2.0 (Generics) and 3.0 (LINQ and Lambdas) had. C# 4 is more scenario based (see list below for some). If you want to:
take advantage of the new features in WCF (default endpoints, improved WCF REST support, etc.);
work with Entity Framework 4 and it's new features along with WCF Data Services to expose your EF model as a data service;
take advantage of some of the multi-threaded enhancements (e.g. Tasks instead of using Threads);
CodedUI tests (more of an IDE thing, not a language thing);
etc.
...then maybe I would. (Most of my projects utilize WCF in some way, so I'm in the process of upgrading.)
I wouldn't upgrade just to upgrade. Upgrade if you have a business/technical reason to do so. You have to weigh the costs (less time coding while you upgrade your environment) with the benefits (latest language, and as one commenter said, happier developers).
Plus, the IDE is nice (although I've found it a little unstable at times). And as w69rdy's comment said, it's backwards compatible. You may want to give the IDE a try and still stay on .NET 3.5 just to try some of its features (like the extension manager and schema comparer).
If your software is fairly static and business critical then an upgrade may present a risk to the production uptime of the business. However, if you plan to continue development of the business' software well into the future then at least planning to upgrade is a step in the right direction. There's no reason to limit one's development to older versions if the company wants its code to keep moving forward. Future problems may have easier and more expressive solutions using newer language capabilities.
There's also certainly something to be said about keeping one's development staff current on technologies. If the business wants its technologies to remain static, it's going to have an increasingly difficult time finding talent over the years.
If upgrading to C# 4 is not a vey large pain for your system, then it's worth it just to have you projects on the new runtime, if .NET 4 were running on .NET 2 like .NET 3.5 is I would say don't bother, but the benefits of being on the newer runtime are futuresafety in this case since there will be future .NET releases based on the .NET 4 runtime, and the upgrade may be more difficult come that time.
I am making the assumption that you're asking if it's worth it when you don't need it because it wouldn't be extremely difficult for you to upgrade, if it would present particular risk and difficulty in your project then it would not be advisable without a sufficient business need for the functionality in .NET 4
If you are using ASP.NET WebForms it might be worth. Take a look at this blog entry.
Web.config files are much cleaner now and css support was enhanced a lot. WebForms Routing is also a core feature under 4.0. Best of all, you finally get full control over your control id's!
In my opinion, WebForms still isn't as nice as ASP.NET MVC, but it got much required love in 4.0.
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 3 years ago.
Improve this question
I have couple of ideas in my brain which I would like to bring out before it's too late. Basically I want to develop a web application which I could sell it to clients. So which technology shall I use to accomplish this? I have been a C and C++ software developer but it's been a very long time since I have developed one. So the things I would like to know is:
Scalability and Performance?
Easy way to develop web application in a faster manner?
Any Framework?
Application server?
and which programming language?
Usually the programming language doesn't really matter. All have their own strengths and weaknesses. All come up with their own best-practices and frameworks.
It's really up to you what's your preference. If you are coming from Microsoft C/C++ I'd use .NET, if you are from Linux world I'd use Java.
Back in the 90s Java was well known as a slow framework, however there was much of myth and the framework architecture is dramatically changed since that. Today, there is no generally slow or fast framework.
You can find thousands of sites in the web that tell you that the one or the other is faster. However, at the end of the day it depends on how you implemented your solution and how you utilized the best features of the framework.
Greets
Flo
I would suggest using C++ with CPPCMS as it's becoming stable and is precisely targeted at high performance web applications.
See if the rationale match your goals.
Build with:
C#, you'll love it (I'm also an old C++ developer)
ASP.Net MVC (Validation, caching, Spark view engine)
Any ORM having a cache layer (I prefer nhibernate)
Database with lots of allocated memory
I kinda think this is almost more like a religious problem, than a real technical issue. For almost every programming language you can find a big website that's using it.
.NET -> Microsoft
Ruby -> Twitter (yes, they have a few issues, but still)
PHP -> Facebook
Java -> Lots of finance companies
Don't know about Phyton, but I'm sure there is.
More important is a good scalable architecture. That is where Twitter kinda screwed it up it seems.
Personally I use ASP.NET. Works fine, is somewhat easy and has a nice IDE. And the market is not so fragmented. Before I used Java with Websphere. Was running on a Sergenti Sun Box, so could definitely handle a lot.
I would more see into what you can get yourself into the quickest. If you know C++ C# or Java are easy to learn.
You should take a look at ASP.NET.
Using ASP.NET has got a lot of advantages, and it is very performant. Here you've got a short list of some advantages:
ASP.NET drastically reduces the amount of code required to build large applications.
With built-in Windows authentication and per-application
configuration, your applications are
safe and secured.
It provides better performance by taking advantage of early binding,
just-in-time compilation, native
optimization, and caching services
right out of the box.
The ASP.NET framework is complemented by a rich toolbox and
designer in the Visual Studio
integrated development environment.
WYSIWYG editing, drag-and-drop server
controls, and automatic deployment are
just a few of the features this
powerful tool provides.
Provides simplicity as ASP.NET makes it easy to perform common tasks,
from simple form submission and client
authentication to deployment and site
configuration.
The source code and HTML are together therefore ASP.NET pages are
easy to maintain and write. Also the
source code is executed on the server.
This provides a lot of power and
flexibility to the web pages.
All the processes are closely monitored and managed by the ASP.NET
runtime, so that if process is dead, a
new process can be created in its
place, which helps keep your
application constantly available to
handle requests.
It is purely server-side technology so, ASP.NET code executes on the
server before it is sent to the
browser.
Being language-independent, it allows you to choose the language that
best applies to your application or
partition your application across many
languages.
ASP.NET makes for easy deployment. There is no need to register
components because the configuration
information is built-in.
I'm developing a website , job portal. I have 2-3 years of ASP.NET webform development experience,
I want to create a professional job portal site (to improve and learn more) but trying to decide on best architecture. Any suggestions or advice will help...
Thanks
Well, there are a number of ways to answer this question, and I'm sure many others will chime in. I'll just say that since your goal is to improve and learn more, and you already have 2-3 years of webform experience, this might be a good opportunity for you to learn MVC. Then you will have experience in both, and can make more informed decisions regarding the best architecture for future projects.
Happy learning!
Whilst nobody can tell you exactly what to do, the team I manage is about to release a new CMS / Job portal using ASP MVC. MVC gives us excellent testability and scalability out of the box and it can be quickly combined with tools such as nHibernate / windsor (IOC) / nCache / jQuery - this ensures that you have a wealth of resources on the internet to help accelerate your development and skill. You can also embrace standards such as XHTML 1.1 strict, which is almost impossible with ASP.Net webforms due to the auto generated HTML
1 other advantage is that you also get away from the dreaded ASP.Net viewstate.
Use ASP.NET MVC if you want to:
learn the ASP.NET MVC framework
use jQuery or similar libraries
really learn web-languages (HTML, CSS, JavaScript)
use Test Driven Development
have a clean separation of concerns
If you don't have the time or will to learn to use the ASP.NET MVC framework correctly, stick with ASP.NET WebForms.
My answer is almost always "ASP.NET MVC." The amount of flexibility and features and testability and maintainabilty and ... heavily outweigh WebForms.
WebForms has the advantages of a rich ecosystem of existing controls and documentation, and is really powerful for some kinds of tasks (complex, multi-form interactions), but I find its limitations get in the way far too often. You have to mold yourself to it.
It really depends on what the end goal of the application is. As Scott Ewers said, if your goal is to learn, then using ASP.NET MVC will expand your breadth of knowledge in the ASP.NET space (since you already know web forms).
Additionally, if this is going to be a public product, you can leverage the testability benefits of MVC and run automated unit tests. Key ideas like Separation of Concerns can also increase long-term scalability and maintainability.
The primary reason why you might choose web forms is if you are rapidly prototyping the job board application. As you know, web forms allows you to drag-and-drop components onto the canvas to quickly create some basic data entry functionality.
There is a herding code podcast from May 13 on the subject.
Herding Code 47: Joe Brinkman on Webforms vs ASP.NET MVC.
I also agree that choosing MVC would have the advantage of allowing you to expand your knowledge. That not being the only reason, given the choice as well I just finished a small MVC project (my first) and let me tell you MVC rocks! Its a great framework which I feel gives you more flexibility and at the same time out-of-the-box tools to create a web app quickly and painlessly. It was my first experience with VS2008 & .NET FW 3.5 & LINQ, and all the guides at www.asp.net helped me go forward quickly (especially the free tutorial chapter from an MVC 1.0 book mentioned here).
I also got to learn JQuery along the way, as it is very much integrated into these new technologies.
One think to take note though is that this being a new tech, version 2 is already being cooked up, so if your project is for the long run, have that in mind and plan accordingly (in my case, being a small project, I'll probably try upgrading my project to version 2 when its officially released). Yet at the same time, having a fully MS (and thus MSDN) supported version 1 was a godsend for me...
Good luck!
I have good experience in Jquery, CSS, HTML, Javascript but not in TDD.
I have time..and willing to learn MVC but wasn't sure MVC is good choice for Job portal or similar site..
This can be considered a shameless self-advertisement but here is my quiz on how to choose between the two:
http://sietch.net/ViewNewsItem.aspx?NewsItemID=101
I was recently tasked by one of my clients to write a paper, or simply a checklist, that would help other lead developers make this same decision.
I posted the first 2 rough drafts on my blog. I am admittedly pro-mvc but the paper/checklist has been we received so it might be helpful.
http://eric.polerecky.com/archives/a-somewhat-less-biases-comparison-of-mvp-and-mvc/[http://eric.polerecky.com/archives/a-somewhat-less-biases-comparison-of-mvp-and-mvc/][1]
I think the most often overlooked benefit of MVC is convention; I really see any convention in webforms projects and while not strictly enforced in MVC projects at least its there.
i started developing our current app in webforms, mvc wasn't available when development started.. i've chosen the MVP pattern, with URL rewrite HTTP module. currently i'm investigating plugging in some MVC into this, basically to use the front-controller instead of using page-controllers. the other things in already established MVP architecture with web forms in my app give me more flexibility than pure MVC approach without WebForms, which i like, although require a bit more code than MS MVC examples (never tried it for real project to see if it stays that way, like in those examples in screencasts).
what i don't like with MVC is mixing control code inside templates - i believe loops, ifs and stuff like that just shouldn't belong inside the template. but a couple days ago i've ran into Spark view engine that looks kind of promising in that segment, although not still close to the Tapestry 5 (a component-based webGUI framework) in the java world.
But the above mention suggestion to mix both might work for you to explore MVC world and have the safe ground to fallback to if something won't work for you might be ok for you.