List asp.net topics for interview [closed] - asp.net

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
I am having 3 years of experience in asp.net. I need to list down topics that are related to web development
I have listed the following topics. Please add your topics if in case i have missed
A.OOPS
Classes
Objects
Polymorphism
Encapsulation
Abstraction
Inheritance
Interface
Abstract class / virtual cass
Access Modifiers
Overloading vs Overriding
B. C#
Boxing-Unboxing
Delegate- event
Collections
Generics
Value Type vs Reference Type
C. ASP.NET Topics
Authentication and Authorization
state Management
XML/XSL/XSLT
Web Services
Array List, Hashtable, Generices
Themes, Skins and Master Pages
Remoting
Reflection
Serialization
Caching
Threading
Localization
HTTP Handlers / HTTP Module
ASP.NET Entity f/w
JSON
D. Designing
HTML
CSS
XTML (Also Themes, skins and master pages)
E. Advanced ASP.NET Concepts
WCF
WPF
JQUERY
Silverlight
AJAX
DNN
Axure
MVC
F. ADO.NET
H. SQL Server
Normalization
SP/ Functions (differnce), views
Triggers
PLEASE POST THE TOPICS THAT I HAVE MISSED OUT

Looks like a good list, but worth knowing about the following too I reckon
LINQ
O/R Mapping - eg Nhibernate
Dependency Injection / Inversion of Control - eg. Windsor / structureMap
Design patterns - eg MVC MVP SOA etc
SQL Full-text search
SQL 2008 new features- eg CTEs
New features in asp.net / C# 4.0

Related

ASP.NET MVC 5 vs. AngularJS / ASP.NET WebAPI [closed]

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.

Need help selecting new .net framework to create a very thin RESTful service [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
My team is building a new application architecture where the bulk of our logic and processing is going to be on the client using Angular.js.
Our limitation is our server, specifically we have no access to our web-server and stuck with currently only having the ability to use .net/IIS. Our server is configured with .net 4.0, although I may be able to push for an upgrade to 4.5.
Our last project we created a WCF4 configure-less setup to create our RESTful services. This solution was workable but I was hoping there might be some better frameworks/APIs available now to set up the lightest possible .net server.
We focus primarily on our javascript so we have fallen off in our .net knowledge, so what is the current "best" or most used .net RESTful service solutions out there?
I would look at ServiceStack : http://www.servicestack.net/
I've used it for a few projects and I can say that you can get up and running very quickly, especially if you start with one of the tutorials or example packages (of which there are plenty). It's plugin-based architecture means you can buy in to as many or as few of the built-in features that it has, including authentication, authorization, and session management. It also "plays nice" with MVC, so if you have controllers that also want to use features, such as the built-in authentication / authorization and session management features, then it's a snap.
It was built with efficiency and speed in mind. It uses the best of the best when it comes to third-party libraries that it uses. Everything is well thought-out and planned.
Asp.net's Web API is the latest and greatest that Microsoft itself offers in building simple REST services. You can leverage the simple-but-extensible routing structure of ASP.NET MVC, and define your services using simple MVC-style controller actions that return plain old C# objects, which get serialized into JSON results.
I can't speak specifically to the "lightweight"-ness of Web API: it's likely that ServiceStack would perform better. But in terms of keeping simple code, but still having the flexibility to do more advanced things when you need to, Web API has a lot to offer.

ASP.Net Membership Your Thoughts? [closed]

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 am building a project using ASP.Net 4 and MVC3 using C#.
The ASP.Net Membership Provider is integrated well into the framework.
Role check and some identity information but I have an issue.
It's limited flexibility.
Should I build a new user management system from the ground up and lose the convenient short codes within controllers ect....?
Are there any alternative?
Worry about hashing passwords, caching stuff, session management just gives me a headache when I think about building something from scratch.
I use the ASP Membership mainly for logging-in (only). Then I use database-specific tables for highly-customized user-features that ASP Membership doesn't easily accomodate (or at all). If any custom-feature "can" be (easily) accomodated by the ASP Membership Db...then I use it...but mostly, I put custom user-specific functionality in the target database (in-question).
Also...
Because the ASP Membership functionality can manage many databases at the same time, I run a separate ASP Membership database instance (apart) from those it manages. Doings so has proven clean & friendly for me.
There wouldn't be a lot of advantage in writing your own membership system 'from the ground up'.
You'd be better implementing a custom Membership Provider and Role Provider - meaning that you can easily use the [Authorize] attribute, and other built in membership roles stuff, and then add any extra stuff you need into your custom providers.
Have a look here and here to see what is involved in a MembershipProvider and RoleProvider - just derive from the abstract MembershipProvider and RoleProvider and provide your own implementations

ASP.NET MVC vs. Webforms vs. HTTP Handlers (.ashx) - which is the most lightweight? [closed]

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.

ASP.NET MVC / ASP.NET WebForm data access application - what's the best architecture? [closed]

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.

Resources