I am giving a small presentation to a group of Java developers and looking for some core areas to target. Ideally I would like to only talk about the core concepts in ASP.NET.
I am coming up with
Authentication
Session State
ASP.NET MVC
LINQ (more .net)
Any more that I should be considering?
One of the most important things to learn is the ASP.net lifecycle. It makes debugging much more worthwhile...
For ASP.net WebForms -
MSDN Documentation
Useful cheat sheet
It is important to keep the life cycle in mind when developing web based applications.
I'd focus on ASP.NET MVC (because while MVC is bread and butter in Java, that's a pretty cool implementation) and LINQ, especially the runtime query construction you can do with something like PredicateBuilder (because Java can't do that and it's a very good way to demonstrate the unique capabilities of C#).
Related
Ive been confused about ASP.NET MVC.
As some said, MVC is better than ASP.NET. As some said, they are completely the same thing.
And my colleges debate that MVC is just an extension of asp.net, where asp.net is already in the form of MVC.
In fact I am starting web developing from scratch. If someone might help to clear the fog front of me, it would help a lot.
All ASP.NET web frameworks are build on top of Microsoft ASP.NET Framework. The unique feature of Web API is that it can be used with both MVC and WebForms applications to provide truly restful HTTP services.
Regarding the choice of suitable Asp.NET framework: you may get more information from official source - www.asp.net.
General rule of thumb is the architectural design how you want to build your application.
ASP.NET MVC promotes a cleaner separation which makes the developer think more in depth about design and code separation than traditional web forms.
There are endless debates about what is better but true benefits of ASP.NET MVC as
testability
more control over the rendered HTML
separation of concerns. However with MVC there is much more to learn for the developer.
ASP.NET WebForms - will always be around because some see it as a rapid application development tool. Just drag and drop and let ASP.NET handle the posting, state etc
ASP.NET Web API - is a framework that makes it easy to build HTTP services that reach a broad range of clients, including browsers and mobile devices. ASP.NET Web API is an ideal platform for building RESTful applications on the .NET Framework.
All in all, each of them has certain business solutions to be considered as required.
References to look for comparison:
ASP.NET MVC vs WebForms: speed and architecture comparison
ASP.NET Roadmap: One ASP.NET – Web Forms, MVC, Web API, and more
ASP.NET is the name of the overall web framework. There are a few different technologies that are built on ASP.NET. Two popular examples of these technologies are WebForms and MVC.
WebForms promotes a programming model that looks a lot more like Windows Forms. It attempts to abstract away the stateless nature of the web, and encourages you to use server-side controls instead of HTML. Because WebForms was the primary way to write web applications on ASP.NET for a long time before MVC came out, you'll often see people talk about "ASP.NET" as the same thing as WebForms. This is part of the reason for your confusion. ASP.NET WebForms is very different from ASP.NET MVC, but they are both built on ASP.NET.
ASP.NET MVC gets away from server-side controls. It eliminates the abstractions, allowing you to have closer control over the actual HTML that gets generated. For developers of modern applications, this is very useful because it makes it much easier to use AJAX and rich client-side javascript.
(Humble Opinion incoming)
ASP.NET (in terms of using Webforms) is programming the web for a WinForms developer. You "bind" events, you have "controls" and everything (sessionstate) is stored in a huge hidden field within the page so it knows where it left off from the previous call. You rely heavily on this information being present which is why everything you do needs to reside in that master form wrapping the entire page.
On the other hand, MVC is bringing C# .NET programming back to the web the way the web was intended. No bloat, no hidden fields, no heavy bindings. It's brings everything back to the classic "i have this form and now I need to process it". Arguably, the real magic is the routing methods and the "automatic binding" of submitted fields to an object. (if fields x, y & z are submitted and your action is looking for FooBar with the properties x, y & z it's automatically converted for you.
ASP.NET is common to both WEB-API and ASP.NET MVC. I assume you wonder about MVC or WEB-API.
MVC is a controller / model based with Views. Although the controllers can be used for AJAX json purposes. MVC is a good way to build a serious Browser based Application. The WEB-API allows you to build simple http server features, not necessarily Browser related. Good for REST style programming. Very flexible and a good alternative to WCF services. The are good tutorials on Both on the official ASP.NET site. START here http://www.asp.net/get-started
choose depends on your project n you. I suggest you to choose MVC because its productivity is very high we r using it since 1 year and found better than webforms.
for more knowledge please visit http://www.asp.net/mvc
The choice depends completely on you, I have been developing MVC application since 2010, its going to be over 2 years now have worked with almost all the versions of MVC both with Razor and aspx view. I have also worked on ASP.Net webform based applications.
With MVC you will not get built in controls, you will have to develop every control you want to use, you will have to rely mostly on html controls, while with web forms you will get advantage of using built in controls, Even getting help from other developers in your surroundings may be easy for webforms as you can easily get a webform developer.
But on the other hand with MVC the maintability is very high. As for as productivity is concerned, its very high once your are accustomed to it, initially it will be low as you will be in learning phase. Don't forget to use Entity Framework.
You may also consider developing your App using WebAPI, if it suits your scenario.
I am starting a new project in VB /.Net Framework 2.0 for a company corporate website with data driven forms. So should I go further with Asp.net MVC or Asp.Net web forms and WHY ??? We are not ready for Ajax now but later.
And also we have DevExpress components.
Actually I see ASP.NET MVC as next generation in that it is an evolution - trying to be a better programming environment, as software development for web apps asks for something more testable.
It is a huge beast. Decide based on features whether you need it. MVC has less documentation and is a lot harder to master thanks to a less RAD approach, but it seems that once you are in, it will be quite a better experience. If you have a web application (like stackoverflow.com) then it may be a good approach.
DevExpress components - have fun... throwing them away. Like most ASP.NET components they will not work or only work very partially. Totally different approach.e
ASP.Net MVC is not "next generation" ASP.Net. It's an alternative approach to design that can be more beneficial depending on the kind of project you're working with. Without more information about the particular type of project you're working on no one can give you any informed recommendations.
I would like to know how I can go about implementing my own version of a MVC framework in ASP.NET? I know there already is Microsoft provided ASP.NET MVC framework, but I want to learn MVC and thought the best way would be to implement my own flavor of a MVC framework on top of ASP.NET. Any thoughts / guidance ?
Also, can anyone point me to a page where I can learn more about how microsoft implemented ASP.NET MVC ? I'm more interested in learning about the under the hood plumbing that goes on to implement the framework on top of asp.net, do they use HttpHandlers / HttpModules ?
Thanks.
You want to learn about a concept by reinventing an existing framework that already does that concept better than you will? That sounds like quite a rabbit hole to venture into.
Why not learn MVC by learning ASP.NET MVC? What's your reasoning for why that's not a valid way to learn the concepts? Learning a proven framework will be a much better approach than what you're considering.
EDIT: One other thing to consider. Knowing how to use ASP.NET MVC (or Rails, or insert-MVC-framework-here) would be a much more useful and marketable skill than the ability to roll your own MVC framework from scratch (even though that might prove more intellectually stimulating).
You can get the source for ASP.NET MVC from here: http://aspnet.codeplex.com/releases/view/41742
MVC is an architectural pattern that is not dependent on ASP.NET or any framework.
I would not advise trying to implement it on top of ASP.NET if you are just looking to learn about the Model View Controller pattern. ASP.NET will impose too many implementation details when you should instead be concentrating on the overall concept such as separation of concerns, single responsibility.
The ASP.NET MVC framework is simply an implementation of the Model View Controller pattern that runs on top of ASP.NET. Like most implementations it contains variations on the basic MVC pattern to better suit web applications and the underlying framework. So trying to re-implement ASP.NET MVC will give you a non-standard understanding of the pattern.
Martin Fowler explains the fundamental ideas of MVC in the book: Patterns of Enterprise Application Architecture.
I have studied a lot of starter kits for ASP.NET and ASP.NET MVC really is awesome compared to web forms, because it runs fast and developement is easy. But when I fit ASP.NET MVC, LINQ in a site with a lot of visitors and mostly controls based website, I got so many issues in my mind.
Let's say I want to build a website which is small scale, but got a lot of visitors and mostly controls based (i.e. TV Show Information website). You've got shows, episodes.
Is it efficient and easy when you use n-tier architecture in ASP.NET MVC?
Should I create my own entities in Business Logic Layer or use SQL Tables as entities?
Should I use Application Cache in it to save all shows in cache?
I like the Presentation Layer of MVC using LINQ but when it comes to DataAccess and BusinessLogic its confusing me. Can anyone help?
My 2 cents:
In my opinion there is no difference between using ASP.Net MVC or Web Forms in an N-Tier architecture. We use WCF to comunicate between tiers.
We create Data Transfer Objects that are not the Entity Framework Entities. However, I expect this to change with the next version of Entity Framework which introduces POCO.
Not sure what you mean by "shows". ASP.Net has its own caching for pages, for caching data you could use Enterprise Library.
Just to clarify I define a Tier as a separate machine, where as a layer would be a separate dll.
i've just read an amazing article regarding working n-tier with asp.net mvc
check it out:
http://www.codeproject.com/KB/aspnet/ASP_NET_MVC_WITH_EF.aspx
it's all about right architecture working with ASP.NET MVC Framework + N-tier + Entity Framework
enjoy!
:-Dan
I highly recommend the NerdDinner ASP.NET MVC Tutorial. You can get more info on it and download the free chapter from ScottGu's blog post here.
In the code that accompanies that sample chapter there is a pretty good architecture structure that you can use to base your architecture on. I have gone back to it several times when trying to see how to architect something in ASP.NET MVC.
Have you built your first application in ASP.NET MVC yet, or are you still studying?
I think you should start with an architecture similar to NerdDinner and refactor after you become more familiar with how ASP.NET MVC works.
If you really are well versed in multi-tier, then you should be able to figure it out without help from us. Try some things. Do what works. Try not to worry so much about being "correct."
Some of what you are asking in your question is premature if you haven't written your first ASP.NET MVC application yet.
By the way, I found Scott Hanselman's "File/New/NerdDinner" video both enlightening and entertaining: http://videos.visitmix.com/MIX09/T49F
I use my own flavor of n-Tier with MVC because I don't like LINQ-to-SQL and the Entity Framework. I've also written some T4 templates that generate those objects and the use the Enterprise Library to interact with the DB. It's up to you, whatever works.
We are about to embark on a large enterprise application. I am seriously considering using ASP.NET MVC because:
We need to use Microsoft technology (biz logic is all C#)
Performance is critical
I'd like to test as much as possible
My team has only used PHP for web development, but are very experienced with .NET winforms (so either way we have a learning curve). My concern is that some people have expressed concerns about ASP.NET MVC's scalability to large apps. But from what I read webforms have their own problems as well.
Should I be reconsidering webforms, or stick with my gut and use ASP.NET MVC?
Related:
Should I build my next web app in ASP.NET MVC?
https://stackoverflow.com/questions/521388/from-webforms-to-asp-net-mvc
ASP.NET webforms are heavyweight and drop a crapton of stuff on your webpages, both in html/javascript and serialized viewstate. I remember my first ASP.NET website causing the GC to blowed up because of all the short-lived objects being rehydrated from that godawful viewstate. Oh, when I was young and naive (i.e., 2 years ago)... You have to have a very good understanding of webforms to build scalable websites from them. Possible? Definitely. Easy? Not.
ASP.NET MVC is harder to code initially, but is SO much easier to develop than webforms. The hardest things to learn are 1) the conventions aka "magic strings", 2) Html + inline code aka ASP and 3) html forms.
With MVC, you can't get away with the state nightmare that is so common to webforms development, which means that means your webpages are meth-addict slim. It also means you have to code your state a little smarter. The code is also MUCH simpler and scales MUCH better than traditional webforms, imho.
Also, testing with ASP.NET is near impossible, due to the hard-coded and unmockable dependencies baked into the framework. ASP.NET MVC replaced all of these with System.Web.Abstractions members that are mockable wrappers around these badly-designed and untestable objects.
Run, don't walk, to MVC.
For the obvious-impared, if you use a framework that sits ontop of the ASP.NET framework, such as MVC or any other that you wrote or that somebody else wrote, OBVIOUSLY some of these remarks don't apply.
If, on the other hand, you code as early man did against the ASP.NET webforms model (e.g., Response.Write() in Page_Load), my comments apply.
Can you write code that's testable against ASP.NET? Sure. Can you do it without including special testing code you or somebody else wrote? Sure. If you have TypeMock.
ASP.NET WebForms is very much like Winforms and allows for RAD (rapid application development). It's very fast to get something in no-time. Problem with this is testing can be a major pain and if used for anything public facing can mean some major issues with ViewState. WebForms can hold state making things like a wizard a breeze to use.
ASP.NET MVC on the other hand can take a little longer to develop with and requires that devs understand how HTTP works. It's a stateless architecture meaning each request is it's own little world and usually has no knowledge of previous requests. The framework also allows for high testability.
As far as performance goes they're probably the same because ASP.NET MVC is just a framework built on top of the existing ASP.NET architecture. Though for client-side experience I'd say MVC is a bit faster.
As far as scalability I would say they're about the same as far as technical goes. How as for using the API and integrating it MVC would probably be a bit easier.
The website you're using right now to ask this version question is built on ASP.NET MVC and they have 2 web servers and a beefy db server.
ASP.NET MVC is not a problem for Enterprise, but neither is ASP.NET, Silverlight, etc. They are all UI technologies. The majority of your application logic should exist in libraries beneath the UI layer anyway, so pretty much any UI can be used.
We need to use Microsoft technology
Performance is critical
I'd like to test as much as possible
Based on the above, ASP.NET MVC will work. But, you can move the code down below the UI and test. If your algorithms are below the UI, you can tune them without altering the UI. And, if the UI layer is very thin, the perf hit for the UI is negligible.
No. One thing that the ASP.NET MVC has over ASP.NET Web Forms in terms of performance is that it doesn't make use of a control tree. The control tree consumes a lot of server side memory and keeps the garbage collector very busy on pages with many controls. I would argue that you would get superior performance from the ASP.NET MVC. The unit testing aspects of it are a real win to.
The flip side of this is that you can't use all of the handy out of the box controls that you get with ASP.NET Web Forms and you'll probably end up doing more client side JavaScript development so the initial development budget would probably need to be greater if you choose ASP.NET MVC over Web Forms, but you would have a superior solution for the long term.
Stick with your gut. ASP.NET MVC helps facilitate testing because almost the entire API derives from interfaces.
Have used WebForms for years and never liked them. Now use Asp.Net MVC for some years and this is so much better. Certainly woud recommend MVC.
Asp.Net MVC has an excellent architecture and is open source. So if you would identify bottelnecks in the http processing chain you could fix it. Most time you would be able to fix performance issues using one of the many extension points provided by Asp.Net MVC, like Binders as an example.
I would say go with MVC if you need or want its features . If you are building a line-of-business application such as an ERP or CRM system, I would use Webforms; if you are building a portal or community wiki type site I would go with MVC hands down. Ultimately it comes down to preference and what exactly your enterprise application needs to accomplish.
"With MVC, you can't get away with the state nightmare that is so common to webforms development, which means that means your webpages are meth-addict slim"
Upmodded for that quote!
My opinion: use ASP.NET Webforms.
Disable ViewState in the Web.Config.
There is no need to preserve state because everything you really need is in the Request object.
Use Javascript in conjunction with AJAX for data retrieval to render your UI controls client-side.
Create serverside wrappers in the form of control tags for your client-side component renderer.
This is how I've been working for ages now, and it's fast, reliable, testable and organized.
It does take some time to setup a decent framework for this working method, but eventually it will rule.
I rather have no spaghetti code like MVC. Been there with PERL/PHP and classic ASP.
Everything I've read about asp.net MVC says that it is able to serve up more page requests than asp.net webforms.
I have some doubts about its stability and security though. Both of these stem from the fact that it's not even released and even with the RC we saw some changes to the framework. I am sure there will be more changes as time goes on and things are found. It's new so there are not really "best practices" out for it and there is a not a wealth of experience out there detailing the small issues or gotchas that you might run into.
I've been using it and it does result in smaller pages and faster performance. But there are so many things I can do in webforms that I have no idea how to do with mvc because mvc does not promote the use of the webforms controls.
If you're able to use stored procedures then you don't need a big middle-tier like those generated by MVC. All you have to do is pass XML to your stored procs through a simple HTTP handler, get results back from a stored proc, and convert the results to JSON. MVC and other middle-tier stuff only serves to make money for companies that sell IDEs like VS.