How and when to use Singleton classes

It’s a pretty well known pattern, but I want to discuss what a Singleton class is first. In a nutshell, a Singleton class is a class that will only have one instance of the class. In certain cases, we want to make sure that we cannot instantiate multiple copies of the object, so we limit it to just one copy. Instead of having a public constructor for our class, we use a private constructor. Then we use a public method (usually named getInstance()) to make sure there is only one copy.


Here is how it looks:

1 2 3 4 5 6 7 8 9 10 11

public class Singleton { private static final Singleton instance;   private Singleton(){}   public static Singleton getInstance() { if (instance == null) instance = new Singleton(); return instance; } }

As you can see, the constructor is private, so we are unable instantiate it in the normal fashion. What you have to do is call it like this:

1	public Singleton singleton = Singleton.getInstance();

When you do this, the getInstance() method then checks to see if the parameter ‘instance’ is null. If it is, it will create a new one by calling the private constructor. After that, it just returns it. Of course, if it is not null, it just returns the existing instance of it. This insures that there is only one copy of the object within your program.

Of course, this post wouldn’t have much meat to it if thats what I left it at. So lets talk about some of the uses of a Singleton class. Also you might at some point as ‘why not just make it static?’, which is a common question, so I will go over that about that as well.

First, what are the uses of a Singleton?. Singleton classes are normally used for things such as a Factory classes, Builder classes and things like that. A few real world examples include the the SessionFactory class in Hibernate – it’s actually a singleton. Or with log4j, when you call its logger, it uses a singleton class to return it. If anyone has used Cairngorm within Flex/Actionscript 3, its model locator is a Singleton.

So why do we want to use singleton’s in these instances? Lets look at the ModelLocator example within Cairngorm. The model locator is used within Cairngorm to keep the state of data within our Flex application. But the reason why its kept in this one object is that it is used across multiple components. The data in one component is usually important to another component, so everything is managed in one central object. It’s quick to realize why we only want one of these in our program. If not, it would be pretty tough to maintain state if other components are affecting data providers that others are using.

Another question that usually comes up when it comes to using a Singleton is “Why not just use a static class?”. Static classes still have many uses and lots of times, people get confused and will use a Singleton as much as possible. One easy rule of thumb you can follow is if it doesn’t need to maintain state, you can use a Static class, otherwise you should use a Singleton.

So here is a quick list of uses for static classes:
Math.pow(double a, double b);
Interger.parseInt(String s);
Interger.toString(int i);

As you can see, the state of these methods don’t matter. You just want to use them to perform a simple task for you. But if you coding your application and you are using a central object where state does matter(such as the ModelLocator example), then its best to use a Singleton.

The next reason you may want to use a Singleton is if it is a particularly “heavy” object. If your object is large and takes up a reasonable amount of memory, you probably only one of those objects floating around. This is the case for things like a if you have a factory method that is particularly robust, you want to make sure that its not going to be instantiated multiple times. A Singleton class will help prevent such the case ever happening.

The Singleton is a simple and powerful design pattern. Newer programmers may not realize what potential it has and will over look it. Others may love it so much and end of overusing it in the wrong way.

ASP.NET Interview Questions on Data Access Security

What are the best practices to follow to secure connection strings in an ASP.NET web application?
1. Always store connection strings in the site's Web.config file. Web.config is very secure. Users will not be able to access web.config from the browser.
2. Do not store connection strings as plain text. To help keep the connection to your database server secure, it is recommended that you encrypt connection string information in the configuration file.
3. Never store connection strings in an aspx page.
4. Never set connection strings as declarative properties of the SqlDataSource control or other data source controls.Why is "Connecting to SQL Server using Integrated Security" considered a best practice?Connecting to SQL Server using integrated security instead of using an explicit user name and password, helps avoid the possibility of the connection string being compromised and your user ID and password being exposed.

What is the advantage of storing an XML file in the applications App_Data folder?
The contents of the App_Data folder will not be returned in response to direct HTTP requests.
 What is Script injection?
A script injection attack attempts to send executable script to your application with the intent of having other users run it. A typical script injection attack sends script to a page that stores the script in a database, so that another user who views the data inadvertently runs the code.What is SQL injection?A SQL injection attack attempts to compromise your database by creating SQL commands that are executed instead of, or in addition to, the commands that you have built into your application.What are the best practices to keep in mind when accepting user input on a web application?
1. Always use validation controls whenever possible to limit user input to acceptable values.
2. Always check the IsValid property of the aspx page. Run the server side code only if the IsValid property value is true. A value of false means that one or more validation controls have failed a validation check.
3. Always perform server side validation irrespective of client side validation being performed or not. This will protect your web application even if the client has by passed the client side validation by disabling javascript in the web browser.
4. Also make sure to re validate user input in the business logic layer of your application.What are the steps to follow to avoid Script Injection attacks?
1. Encode user input with the HtmlEncode method. This method turns HTML into its text representation.
2. If you are using the GridView control with bound fields, set the BoundField object's HtmlEncode property to true. This causes the GridView control to encode user input when the row is in edit mode.What are the steps to follow to avoid SQL Injection attacks?Always use parameterized queries or stored procedures instead of creating SQL commands by concatenating strings together.

Can you encrypt view state data of an aspx page?
Yes, you encrypt view state data of an aspx page by setting the page's ViewStateEncryptionMode property to true.

ASP.NET Interview Questions on caching

What is caching?
High-performance Web applications should be designed with caching in mind. Caching is the technique of storing frequently used items in memory so that they can be accessed more quickly. Caching is important to Web applications because each time a Web form is requested, the host server must process the Web form’s HTML and run Web form code to create a response. By caching the response, all that work is bypassed. Instead, the request is served from the reponse already stored in memory.

Caching an item incurs considerable overhead, so it’s important to choose the items to cache wisely. A Web form is a good candidate for caching if it is frequently used and does not contain data that frequently changes. By storing a Web form in memory, you are effectively freezing that form’s server-side content so that changes to that content do not appear until the cache is refreshed.

What directive is used to cache a web form?
The @OutputCache page directive is used to cache a Web form in the server’s memory.

What is the use of duration attribute of @OutputCache page directive?
The @OutputCache directive’s Duration attribute controls how long the page is cached. For example if you set the duration attribute to 60 seconds, the Web form is cached for 60 seconds.

The first time any user requests the Web form, the server loads the response in memory and retains that response for 60 seconds. Any subsequent requests during that time receive the cached response.

After the cache duration has expired, the next request for the Web form generates a new response, which is then cached for another 60 seconds. Thus the server processes the Web form once every 60 seconds at most.

What are the 2 required attributes of the @OutputCache directive?
The @OutputCache directive has two required attributes:
1. Duration
2. VaryByParam.
How do you cache multiple responses from a single Web form?
The VaryByParam attribute lets you cache multiple responses from a single Web form based on varying HTTP POST or query string parameters. Setting VaryByParam to None caches only one response for the Web form, regardless of the parameters sent.

You can also cache multiple responses from a single Web form using the VaryByHeaders or VaryByCustom attribute.

The VaryByCustom attribute lets you cache different responses based on a custom string. To use VaryByCustom, override the GetVaryByCustomString method in the Web application’s Global.asax file.

Is it possible to cache a web form without using @OutputCache directive?
Yes, you can cache a web form using the Response object’s Cache property, which returns an HttpCachePolicy object for the response. The HttpCachePolicy object provides members that are similar to the OutputCache directive’s attributes.

Give a simple example to show how to cache a web form without using @OutputCache directive?
For example, the following code caches the Web form’s response for 60 seconds:
private void Page_Load(object sender, System.EventArgs e)
{
// Cache this page
DateTimeLabel.Text = System.DateTime.Now.ToString();
// Set OutputCache Duration. Response.Cache.SetExpires(System.DateTime.Now.AddSeconds(60));
// Set OutputCache VaryByParams.
Response.Cache.VaryByParams["None"] = true;
// Set OutputCache Location.
Response.Cache.SetCacheability(HttpCacheability.Public);
}

The preceding code is equivalent to the following OutputCache directive:
@ OutputCache Duration="5" VaryByParam="None" Location="Any"

What is @OutputCache directive’s Location attribute and the HttpCachePolicy object’s SetCacheability property used for?
The @OutputCache directive’s Location attribute and the HttpCachePolicy object’s SetCacheability property determine where Microsoft ASP.NET stores cached responses. By default, ASP.NET caches responses at any available location that accepts cache items - the client, proxy servers, or the host server. In practice, those locations might or might not allow caching, so you can think of the Location/SetCacheability setting as more of a request than a command.

What is HttpCachePolicy object’s SetAllowResponseInBrowserHistory method used for?
You can override the cache location settings using the HttpCachePolicy object’s SetAllowResponseInBrowserHistory method. Setting that method to True allows the response to be stored in the client’s history folder even if the location setting is None or Server.

What are the advantages and disadvantages of a layered architecture

The following are the advantages of a layered architecture:

Layered architecture increases flexibility, maintainability, and scalability. In a Layered architecture we separate the user interface from the business logic, and the business logic from the data access logic. Separation of concerns among these logical layers and components is easily achieved with the help of layered architecture.

Multiple applications can reuse the components. For example if we want a windows user interface rather than a web browser interface, this can be done in an easy and fast way by just replacing the UI component. All the other components like business logic, data access and the database remains the same. Layered architecture allows to swap and reuse components at will.

Layered architecture enables teams to work on different parts of the application parallely with minimal dependencies on other teams.

Layered architecture enables develop loosely coupled systems.

Different components of the application can be independently deployed, maintained, and updated, on different time schedules.

Layered architecture also makes it possible to configure different levels of security to different components deployed on different boxes. sO Layered architecture, enables you to secure portions of the application behind the firewall and make other components accessible from the Internet.

Layered architecture also helps you to test the components independently of each other.

The following are the disadvantages of a layered architecture:                

There might be a negative impact on the performance as we have the extra overhead of passing through layers instead of calling a component directly.

Development of user-intensive applications can sometime take longer if the layering prevents the use of user interface components that directly interact with the database.

The use of layers helps to control and encapsulate the complexity of large applications, but adds complexity to simple applications.

Changes to lower level interfaces tend to percolate to higher levels, especially if the relaxed layered approach is used.

F Written Test HR Round Subscribe C# Videos C# Programs Support Us What is the difference between layers and tiers

Layers refer to logical seperation of code. Logical layers help you organise your code better. For example an application can have the following layers.


1)Presentation Layer or UI Layer
2)Business Layer or Business Logic Layer
3)Data Access Layer or Data Layer


The aboove three layers reside in their own projects, may be 3 projects or even more. When we compile the projects we get the respective layer DLL. So we have 3 DLL's now.


Depending upon how we deploy our application, we may have 1 to 3 tiers. As we now have 3 DLL's, if we deploy all the DLL's on the same machine, then we have only 1 physical tier but 3 logical layers.


If we choose to deploy each DLL on a seperate machine, then we have 3 tiers and 3 layers.


So, Layers are a logical separation and Tiers are a physical separation. We can also say that, tiers are the physical deployment of layers.

Tiers:
1) Presenation Tier or UI Tier (Hosts the Presentation Layer or UI Layer). This can be considered as web server in case of an ASP.NET web application.
2) Application Tier or Business Tier (Hosts Business Layer or Business Logic Layer).
3) Data Access Tier or Data Tier (Hosts Data Access Layer or Data Layer).
4) Database Tier - SQL Server or Oracle (or any other database) which has tables, stored procedures and other database objects.


In general the following are the responsibilities of each layer or tier:


1)Presentation Layer or Tier is usually responsible for interacting with the user.
2)Business Layer or Tier is responsible for implementing the business logic of the application.
3)Data Access Layer or Tier is responsible for encapsulating the code that accesses the persistent data stores such as a relational database.

What is the process for strong naming an assembly

What is the process for strong naming an assembly ?
or
What is the purpose of strong naming tool ( sn.exe ) in .NET ?

In .NET, the assembly name usually consists of 4 parts as listed below.
1. Simple Textual Name
2. Version Number (The version number is also divided into 4 parts)
3. Culture
4. Public Key Token

If an assembly contains, all the 4 parts, then the assembly is a strongly named assembly, other wise the assembly is called as a weak named assembly. In general, when you compile any .NET application, the generated assembly by default will have the Simple Textual Name, Version Number and Culture but not the public key token. If you have to sign the assembly with a public key token, you first have to generate the key pair using key generation tool called strong naming tool (sn.exe). The generated key pair will consist of a private and a public key and are written into a key file. Key files have the extension of .snk.

We now have to associate the key file with the project, so that when we compile the project, the generated assembly is signed using the key pair. To do this, In AssemblyInfo.cs file of the project, specify AssemblyKeyFile attribute as shown below.
              [assembly: AssemblyKeyFile("MyKey.snk")]

The last and final step is to build the project which will automatically sign the assembly using the key file. This process generates the strongly named assembly.

In short, there are 3 simple steps to generate a strongly named assembly.
1. Generate the key pair using strong naming tool, SN.exe.

2. Associate the generated Key file to the project using AssemblyKeyFile, which is present in AssemblyInfo.cs file.

3. Build the project.

Once, you have strongly named the assembly, you can copy it to GAC. There are 2 ways to copy an assembly into GAC.
1. Using simple drag and drop : Drag the generated assembly into the GAC folder. Usually the path for GAC is c:\windows\assembly. On some machines this could be c:\winnt\assembly.

2. Use GAC utility : Use GAC Utility tool(gacutil.exe) as shown below in visual studio command prompt.
               gacutil.exe -i C:\MyAssembly.dll (- i stands for install)

Once, you have successfuly copied the assembly into GAC, notice the four parts of the assembly name. The culture column could be empty, indicating that the assembly is language neutral.

Explain Dependency Injection with an example

One of the very common interview questions, asked these days. This is the most common approach used today to solve dependencies between objects. In many of the enterprise class ASP.NET application, Dependency Injection is a common standard to follow. Let us understand Dependency Injection with an example.
In the example above, Employee class depends on EmployeeDAL class to get the data from the database. In GetAllEmployees() method of the Employee class, we create an instance of the EmployeeDAL (Employee Data Access Layer) class and then invoke SelectAllEmployees() method. This is tight coupling, EmployeeDAL is tightly copuled with the Employee class. Everytime the EmployeeDAL class changes, the Employee class also needs to change. EmployeeDAL cannot be mocked and hence unit testing becomes cumbersome and time consuming.

The same example can be re-written using dependency injection as shown below. First thing to notice is that, we are using interface types instead of concrete types. Using interfaces help us to plugin any implemenation of the interface, with less or no code modification at all. We are not creating the instance of the EmployeeDAL in the Employee class, instead we are passing it as a parameter to the constructor of the Employee class. As, we are injecting an instance of a class into a class that depends on it, we can call this process as Dependency Injection.
Dependency Injection is of 2 types.
1. Constructor Injection
2. Setter Injection.

We have already seen how to use Constructor Injection in the example above. An, example for Setter Injection is shown below. We are injecting an object instance through the Setter property, instead of a constructor. Hence, we call Setter Injection. It is very important to use the property EmployeeDataObject to access the instance of IEmployeeDAL, rather than the private variable employeeDAL. The property checks to see if employeeDAL is null, and throws the exception accordingly.