Tuesday, 14 May 2013

What is the Need of Prism and Composite Applications in .NET?


What is the Need of Prism and Composite Applications in .NET?

Prism is used to design and build rich, flexible, and easy-to-maintain Windows Presentation Foundation (WPF) desktop applications. Prism helps you to make WPF application with loosely coupled components and these components can be easily integrated into the main application. These types of applications are known as composite applications. 

Prism is also used in Silverlight and Windows Phone 7 applications.

Advantages of Prism and Composite Applications

1.  Prism helps in creating an application from modules that can be built, assembled / integrated, and, optionally, deployed by independent teams using WPF or Silverlight.

2. Minimize cross-team dependencies and allow teams to specialize in different areas, such as user interface (UI) design, business logic implementation, and infrastructure code development.

Components of Prism and Composite Applications

1. Shell: The shell is the host application into which modules are loaded. The shell provides the top-level window or visual element that will then host the different UI components provided by the loaded modules.

2. Regions. Regions are logical placeholders defined within the the Shell into which views of Modules are displayed. 

3. Modules: Modules are packages of functionality that can be independently developed, tested, and deployed. The module contains the views and services specific to a piece of the application's functionality. 

Modules use shell's regions for placing content. During initialization, modules use the RegionManager to locate regions in the shell and add one or more views to those regions or register one or more view types to be created within those regions. 

4. Catalog: In a composite application, modules must be discovered and loaded at run time by the host application. In Prism, a module catalog is used to specify which modules to are to be loaded, when they are loaded, and in what order.

5. Bootstrapper: The bootstrapper is used to connect the application with the Prism Library and the Unity or MEF containers and initialize them.

Prism Library source code includes the source code for the Prism Library assemblies, including the core Prism functionality, plus Unity and MEF extensions, which provide additional components for using Prism with the Unity Application Block (Unity) and the Managed Extensibility Framework.

Monday, 13 May 2013

Difference between Build, Rebuild and Clean Solution in Visual Studio?


Difference between Build, Rebuild and Clean Solution in Visual Studio?

Build means compile and link only the source files that have changed since the last build, while Rebuild means compile and link all source files regardless of whether they changed or not. 

The Build Solution option compiles only those project files and components that have changed since the last build. For example consider that you have two projects Proj1 and Proj2 in your solution MySolution. When you compile the solution using Build Solution option after making some changes to Proj1 only Proj1 will be compiled and built but Proj2 will not be compiled since there are no changes to it.

A rebuild removes all the old files (performs a clean) and then builds all the files again.

Rebuild = Clean + Build

Rebuild Solution option builds all project files and components irrespective of the changes made to them.  For example consider that you have two projects Proj1 and Proj2 in your solution MySolution. When you compile the solution using Rebuild Solution option after making some changes to Proj1, both Proj1 and Proj2 will be compiled and built even though there are no changes made to Proj2.

Build is the normal thing to do and is faster. Sometimes the versions of project target components can get out of sync and rebuild is necessary to make the build successful. In practice, you never need to Clean.

When you build the project, the dll file are created/modified, but dll created date does not change. But when you Rebuild your project, the dll files are newly created with the current date .

Types of Build:

There are two types of build. A Release build is optimized and it does not contain any additional code that is created to allow you to debug the program in visual studio. A Debug build is not optimized, and it contains additional code that is used when you are debugging your program.

Difference between Encapsulation and Abstraction in OOPS


Difference between Encapsulation and Abstraction in OOPS

Abstraction and Encapsulation are two important Object Oriented Programming (OOPS) concepts. Encapsulation and Abstraction both are interrelated terms. 

Real Life Difference Between Encapsulation and Abstraction

Encapsulate means to hide. Encapsulation is also called data hiding.You can think Encapsulation like a capsule (medicine tablet) which hides medicine inside it. Encapsulation is wrapping, just hiding properties and methods. Encapsulation is used for hide the code and data in a single unit to protect the data from the outside the world. Class is the best example of encapsulation. 

Abstraction refers to showing only the necessary details to the intended user. As the name suggests, abstraction is the "abstract form of anything". We use abstraction in programming languages to make abstract class. Abstract class represents abstract view of methods and properties of class.

Implementation Difference Between Encapsulation and Abstraction

1.  Abstraction is implemented using interface and abstract class while Encapsulation is implemented using private and protected access modifier.

2. OOPS makes use of encapsulation to enforce the integrity of a type (i.e. to make sure data is used in an appropriate manner) by preventing programmers from accessing data in a non-intended manner. Through encapsulation, only a predetermined group of functions can access the data. The collective term for datatypes and operations (methods) bundled together with access restrictions (public/private, etc.) is a class.

3. Example of Encapsulation

Class Encapsulation
{
    private int marks;

    public int Marks 
   {
      get { return marks; }
      set { marks = value;}
    }
}

4. Example of Abstraction

abstract class Abstraction
{
    public abstract void doAbstraction();
}

public class AbstractionImpl: Abstraction
{
    public void doAbstraction()
   {
       //Implement it
   }
}

Commonly Asked WPF Interview Questions and Answers (Part 2)


Commonly Asked WPF Interview Questions and Answers (Part 2)

I had written some basic WPF interview questions and answers in my previous article "Commonly Asked WPF Interview Questions and Answers (Part 1)". Now its time to dive deep into the WPF and explore some advanced but commonly asked WPF questions. I have written separate articles on following WPF interview questions, so I would not be answering these questions here but I would provide links for them where you can study them in detail. These WPF interview questions cover the concepts of Dependency and Attached Properties, Routed Events and Commands in WPF, Different Modes of Bindings in WPF, Static and Dynamic Resources, Window and Page Controls, Relations of Window Forms and Silverlight with WPF etc.

Following is the list of WPF interview questions and you can find detailed answers of these questions by clicking on them.














Well, this is not the end, I will come with some more WPF interview questions on styles, themes, prism, composites, shell, MEF later on.

Wednesday, 8 May 2013

Difference between Dependency Property and Attached Property in WPF


Difference between Dependency Property and Attached Property in WPF

Attached properties are a type of dependency property. But there is a minor difference between dependency property and attached property in WPF. Lets try to understand them.

1. Concept and Usage of Attached Property and Dependency Property

Attached properties allows container to create a property which can be used by any child UI elements whereas dependency property is associated with that particular elements and can help in notification of changes and reacting to that changes.

Attached properties are basically meant for the container elements.like if you have a grid and you have grid.row, now this is considered to be an attached property of a grid element. Also you can use this property in texbox, button etc to set its place in the grid.

Attached properties are used a lot for layout-related information. For example, Canvas needs Left/Top coordinates, Grid needs a Row and a Column, DockPanel needs a Dock information etc. It would be a mess if all of this had to be declared on every control that can be layouted. So they are declared on the corresponding panel, but used on any control.

2. Implementation of Attached Property and Dependency Property

Attached properties and normal dependency properties include the methods used to register them with the DependencyObject. 

For attached properties, DependencyProperty.RegisterAttached and DependencyProperty.RegisterAttachedReadOnly are used and for dependency properties DependencyProperty.Register and DependencyProperty.RegisterReadOnly are used.

The difference between DependencyProperty.Register() and DependencyProperty.RegisterAttached() is that .Register() is used to register a 'regular' dependency property on a DependencyObject, while .RegisterAttached() is used to set an 'attached' dependency property.

Difference between StaticResource and DynamicResource in WPF


Difference between StaticResource and DynamicResource in WPF

There are lot of differences between Static Resource and Dynamic Resource in WPF. Lets try to understand them with the help of examples below:

1. The major difference between static and dynamic resources is that static resource will evaluate the resource only once while dynamic resource will be evaluated every time the resource needed.

2. Dynamic resource has more performance overhead than static resources because it look up for resources every time it requested or needed.

3. Static resource is faster but it takes little more time to load page or window than dynamic resource because dynamic resources are loaded when you actually use them.

Example of Static and Dynamic Resources

Below example gives you clear picture about Static and Dynamic resource markup extension.

XAML

<Window.Resources>
    <SolidColorBrush Color="LightBlue" x:Key="buttonBackground" />
</Window.Resources>
<StackPanel Name="stkPanel">
    <Button Name="Button1" Content="Button1"
            Background="{StaticResource buttonBackground}"/>
    <Button Name="Button2" Content="Button2"
            Background="{DynamicResource buttonBackground}"/>
    <Button Name="Button3" Content="Button3"
            Background="{StaticResource buttonBackground}"/>
</StackPanel>

Code behind

void StaticAndDynamicResources_Loaded(object sender, RoutedEventArgs e)
{
    stkPanel.Resources["buttonBackground"] = Brushes.Yellow;
}

Output

As shown in above example, three buttons are using buttonBackground resource defined in windows.resources element. Button1 and Button3 are using static resource markup extension while button2 is using dynamic resource markup extension. After loading of my window, I have changed color of buttonBackground resource from Lightblue to Yellow in code behind. So when I run my application, Button2 will have yellow background and rest of the buttons will have LightBlue background. The reason behind for not changing background of Button1 and Button3 because both button uses static resource and static resource is loaded only once with application while button2 uses dynamic resource and it changes every time when it accessed. 

Conclusion: The demerit of DynamicResource is that it reduces application performance because resources are retrieved every time they are used. The best practice is to use StaticResource until there is a specific reason to use DynamicResource.

Binding Modes in WPF: TwoWay, OneWay, OneTime and OneWayToSource


Binding Modes in WPF: TwoWay, OneWay, OneTime and OneWayToSource

The Mode attribute defines the binding mode that will determine how data flows between the source and the target. There are four types of binding modes in WPF:

1. TwoWay Binding Mode
2. OneWay Binding Mode
3. OneTime Binding Mode
4. OneWayToSource Binding Mode

1. TwoWay Binding Mode

You have the view connected with its ViewModel, so every change you make in one of them is reflected into the other. To obtain that kind of behavior, you have to implement the interface INotifyPropertyChange in your ViewModel or using Dependency Properties, instead of normal CLR properties.The default however is two-way.

This type of binding is appropriate for editable forms or other fully-interactive UI scenarios. Most properties default to OneWay binding, but some dependency properties (typically properties of user-editable controls such as the Text property of TextBox and the IsChecked property of CheckBox) default to TwoWay binding. A programmatic way to determine whether a dependency property binds one-way or two-way by default is to get the property metadata of the property using GetMetadata and then check the Boolean value of the BindsTwoWayByDefault property.

2. OneWay Binding Mode

In one way mode, data flows from the source to the target each time a change is made on the source (ViewModel). OneWay binding is the default binding mode for the TextBlock's Text property and does not need to be specified. 

This type of binding is appropriate if the control being bound is implicitly read-only. For instance, you may bind to a source such as a stock ticker or perhaps your target property has no control interface provided for making changes, such as a data-bound background color of a table. If there is no need to monitor the changes of the target property, using the OneWay binding mode avoids the overhead of the TwoWay binding mode.

3. OneTime Binding

Like OneWay binding, OneTime binding sends data from the source to the target; however, it does this only when the application is started. When the DataContext changes, it does not listen for change notifications in the source. 

OneTime binding causes the source property to initialize the target property, but subsequent changes do not propagate. This means that if the data context undergoes a change or the object in the data context changes, then the change is not reflected in the target property. This type of binding is appropriate if you are using data where either a snapshot of the current state is appropriate to use or the data is truly static. This type of binding is also useful if you want to initialize your target property with some value from a source property and the data context is not known in advance. This is essentially a simpler form of OneWay binding that provides better performance in cases where the source value does not change.

4. OneWayToSource Binding Mode

OneWayToSource is the reverse of OneWay binding. Unlike OneWay and OneTime binding, OneWayToSource binding sends data from the target to the source.