UML 2.0 link

Diagram	Description	Learning Priority
Activity Diagram	Depicts high-level business processes, including data flow, or to model the logic of complex logic within a system. See UML Activity diagram guidelines.	High
Class Diagram	Shows a collection of static model elements such as classes and types, their contents, and their relationships. See UML Class diagram guidelines.	High
Communication Diagram	Shows instances of classes, their interrelationships, and the message flow between them. Communication diagrams typically focus on the structural organization of objects that send and receive messages. Formerly called a Collaboration Diagram. See UML Collaboration diagram guidelines.	Low
Component Diagram	Depicts the components that compose an application, system, or enterprise. The components, their interrelationships, interactions, and their public interfaces are depicted. See UML Component diagram guidelines.	Medium
Composite Structure Diagram	Depicts the internal structure of a classifier (such as a class, component, or use case), including the interaction points of the classifier to other parts of the system.	Low
Deployment Diagram	Shows the execution architecture of systems. This includes nodes, either hardware or software execution environments, as well as the middleware connecting them. See UML Deployment diagram guidelines.	Medium
Interaction Overview Diagram	A variant of an activity diagram which overviews the control flow within a system or business process. Each node/activity within the diagram can represent another interaction diagram.	Low
Object Diagram	Depicts objects and their relationships at a point in time, typically a special case of either a class diagram or a communication diagram.	Low
Package Diagram	Shows how model elements are organized into packages as well as the dependencies between packages. See Package diagram guidelines.	Low
Sequence Diagram	Models the sequential logic, in effect the time ordering of messages between classifiers. See UML Sequence diagram guidelines.	High
State Machine Diagram	Describes the states an object or interaction may be in, as well as the transitions between states. Formerly referred to as a state diagram, state chart diagram, or a state-transition diagram. See UML State chart diagram guidelines.	Medium
Timing Diagram	Depicts the change in state or condition of a classifier instance or role over time. Typically used to show the change in state of an object over time in response to external events.	Low
Use Case Diagram	Shows use cases, actors, and their interrelationships. See UML Use case diagram guidelines.	Medium

http://www.agilemodeling.com/essays/umlDiagrams.htm

LINQ interview questions

What is Language Integrated Query (LINQ)?
LINQ is a set of extensions to .NET Framework that encapsulate language integrated query, set and other transformation operations. It extends VB, C# with their language syntax for queries. It also provides class libraries which allow a developer to take advantages of these features.

Difference between LINQ and Stored Procedures.
Stored procedures normally are faster as they have a predictable execution plan. Therefore, if a stored procedure is being executed for the second time, the database gets the cached execution plan to execute the stored procedure.
LINQ supports type safety against stored procedures.
LINQ supports abstraction which allows framework to add additional improvements like multi threading. It’s much simpler and easier to add this support through LINQ instead of stored procedures.
LINQ allows for debugging using .NET debugger, which is not possible in case of stored procedures.
LINQ supports multiple databases against stored procedures which need to be re-written for different databases.
Deploying LINQ based solution is much simpler than a set of stored procedures.
Pros and cons of LINQ (Language-Integrated Query)
Pros of LINQ:

Supports type safety
Supports abstraction and hence allows developers to extend features such as multi threading.
Easier to deploy
Simpler and easier to learn
Allows for debugging through .NET debugger.
Support for multiple databases
Cons of LINQ:

LINQ needs to process the complete query, which might have a performance impact in case of complex queries
LINQ is generic, whereas stored procedures etc can take full advantage of database features.
If there has been a change, the assembly needs to be recompiled and redeployed.

Disadvantages of LINQ over stored procedures:

LINQ needs to process the complete query, which might have a performance impact in case of complex queries against stored procedures which only need serialize sproc-name and argument data over the network.
LINQ is generic, whereas stored procedures etc can take full advantage of the complete database features.
If there has been a change, the assembly needs to be recompiled and redeployed whereas stored procedures are much simpler to update.
It’s much easier to restrict access to tables in database using stored procedures and ACL’s than through LINQ.
Can I use LINQ with databases other than SQL Server? Explain how
LINQ supports Objects, XML, SQL, Datasets and entities. One can use LINQ with other databases through LINQ to Objects or LINQ to Datasets, where the objects and datasets then take care of database specific operations and LINQ only needs to deal with those objects, not the database operations directly.

Choosing Between MVC and MVP Patterns in ASP.NET

Introduction

Lately, ASP.NET developers have been paying increasing attention to the architectural aspect of their applications. However, little effort usually is done to choose the right architectural solution. Developers often make a blind choice in favour of the Model-View-Controller pattern and, specifically, ASP.NET MVC framework, disregarding other possible solutions.

Nevertheless, alternative architectural solutions, such as Model-View-Presenter and corresponding frameworks (MVC#, for instance) do prove themselves more useful than MVC in many situations. That is why ASP.NET developers and architects should be aware of all advantages of MVP pattern over MVC and vice versa to choose the appropriate pattern to be used in a specific application. This article provides guidelines for ASP.NET developers on choosing the right pattern among MVC and MVP, concerning all major differences between them.

Choice criteria

1. UI library used

Most ASP.NET user interface controls rely on the server-side event model to process user gestures. When a user clicks some menu item or a button on a web page, a server-side event gets generated and then handled on default by a View class (Web form class). Thus, the View is the best place to receive user input for most ASP.NET UI libraries, both standard and third-party (such as DevExpress or Telerik Web controls).

However, as seen from the picture below, the Model-View-Controller pattern bypasses the standard ASP.NET request processing scheme, because the incoming gestures in MVC are received by the Controller. Moreover, the form of user requests in the ASP.NET MVC framework (which is based on a URI pattern) makes it difficult to adapt this framework to use with the conventional ASP.NET server-side event model. And, although there are a number of UI libraries compatible with MVC pattern (for example, the Yahoo UI library), generally MVC is not fully suitable for most ASP.NET UI libraries.

The Model-View-Presenter pattern, on the contrary, assumes the View to receive user gestures and then to delegate processing to the Controller. Such a scheme comfortably fits most ASP.NET UI libraries.

To sum up, a developer should consider whether the desired UI library relies on the standard ASP.NET server-side event model. If it does (which is most likely), MVP would probably be a better choice.

2. Controller-View linking

According to the Model-View-Presenter pattern, a Controller has a constant link to the associated View object. This allows a Controller to access its View at any moment, either by getting or setting some View properties.

The Model-View-Controller, on the other hand, provides limited capabilities for communication between the Controller and the View. MVC requires passing all data to the view in a single call, such as Render("OrdersView", ordersParam1, or ordersParam2).

Thus, if an application needs extensive communication between Controller and View objects, MVP is more preferable than MVC.

3. Portability to other UI platforms

Many applications are initially designed to work under tbe Windows platform, and later they get ported to the web environment. Other applications are constructed to operate under multiple UI front-ends from the very beginning. Anyway, portability to other presentation platforms is a question of great importance for numerous systems.

And again, MVP shows itself as a better choice because it is compatible with various UI platforms. For example, MVC# Framework currently supports Windows Forms and ASP.NET Web Forms technologies, and Silverlight with WPF is on the agenda. The MVC pattern, quite the contrary, is good mainly for web applications and hardly fits other presentations.

Therefore, if an application needs or later will need support for multiple GUI platforms, MVP would be the right solution.

4. Tasks support

The Task concept belongs neither to MVC nor to MVP paradigms. However, it is included in some MVC/MVP frameworks for its usefulness. Task is a set of views that a user traverses to fulfil some job. For example, an airline ticket booking task may consist of two views: one for choosing the flight, the other for entering personal information. Tasks often correspond to certain use cases of the system: There may be "Login to the system" and "Process order" use cases and tasks of the same names. Finally, a task may be associated with a state machine or a workflow: For example, a "Process order" task could be implemented with the "Process order" workflow in WWF.

A developer should consider whether tasks can help him build his application and accordingly choose a framework with support for tasks (such as MVC# or Ingenious MVC). Generally, the more complicated an application is, the more likely it could make use of the Task concept.

Summary

You have considered the main differences between two popular architectural patterns: Model-View-Controller and Model-View-Presenter, and have learned the reasons for choosing one of them. The article shows that MVP could be a better choice for ASP.NET applications in many scenarios, and developers should certainly consider MVP frameworks as good alternatives to existing MVC solutions.

http://www.codeguru.com/csharp/.net/net_general/patterns/article.php/c15173