We will take a look into the Object dependencies before digging in more.
Consider a scenario of fetching an employee details and show display in UI. Let us say create a Business logic layer class named EmployeeBAL and a data access layer class named EmployeeDAO

public class EmployeeDao
{
//Some code
}

public class EmployeeBAL
{
var employeeDAO = new EmployeeDao();
//Some code
}

From the above code you will notice one thing that we are creating EmployeeDAO instance inside the Business logic layer class. So here comes the dependency

What is wrong if we have a dependency?

Think about whether your code is unit testable. We cannot fully unit test the EmployeeBAL as it has a dependency on Employee DAO. So we can say as long as the composition of the DAO exists within the BAL we cannot unit test the EmployeeBAL.

You will also notice one more thing here; with this type of implementation you will see a high coupling of BAL and DAL.

How to make it loose coupling?

The basic idea behind Dependency Injection is that you should isolate the implementation of an object from the construction of objects on which it depends.

Coming to the example, we should be isolating the implementation of EmployeeBAL object and the construction of the dependent EmployeeDAO object.

We will see how we can make loosely coupled objects in detail

Constructor based dependency injection

We will have to modify the EmployeeBAL to accept an EmployeeDAO instance within its constructor.

public class EmployeeDao
{
//Some code
}

public class EmployeeBAL
{
EmployeeDao employeeDAO;

public EmployeeBAL(EmployeeDAO employeeDao){
this.employeeDAO = employeeDao;
}
//Some code
}

Property based dependency injection

With property based injection we will have a public getter and setter Property of type EmployeeDao so that the dependency can be externally set.

public class EmployeeBAL
{
Public EmployeeDao EmployeeDataAccess{ get; set; }
}

var employeeBAL = new EmployeeBAL();
EmployeeBAL.EmployeeDataAccess = new EmployeeDao();

Wait!!!

The above ones are just some techniques of injecting the dependency. We are still yet to discuss one more interesting thing Unit Testing.

Are you agreeing that we have removed the DAO creation from the Business Logic EmployeeBAL? Yes it is good but it still depends on the actual instance of EmployeeDao.

Consider the below mentioned implementation of the same sample senarios

interface IDataAccess
{
//Some code
}

class EmployeeDao : IDataAccess
{
//Some code
}

public class EmployeeBAL
{
private IDataAccess dataAccess;
public BusinessFacade(IDataAccess dao)
{
dataAccess = dao;
}
}

You can notice we are doing a constructor dependency injection but most important thing here
is we are using Interface type than creating a strongly typed object.

The advantage that we are getting here is we can have an in memory data access object of
IDataAccess interface type and we can easily inject the dependency to the EmployeeBAL.
By this way we no need to have the actual database dependency.

Are you happy that we can unit test the BAL without the data access dependency?

Advantages of Dependency Injection

The primary advantages of dependency injection are:
Loose coupling
Centralized configuration
Easily testable

The post Dependency Injection in C# .NET first appeared on Student Projects.

A delegate in C# is similar to a function pointer in C or C++. Using a delegate allows the programmer to encapsulate a reference to a method inside a delegate object. The delegate object can then be passed to code which can call the referenced method, without having to know at compile time which method will be invoked.

The signature of a single cast delegate is shown below:

delegate result-type identifier ([parameters]);

where:

• result-type: The result type, which matches the return type of the function.
• identifier: The delegate name.
• parameters: The Parameters that the function takes.

Delegates allow a clearer separation of specification and implementation. A delegate specifies the signature of a method, and authors can write methods that are compatible with the delegate specification.

Multicast delegates

With multicast delegate, it is just like a normal delegate but it can point to multiple functions so on invocation of such delegate it will invoke all the methods and functions associated with the same one after another sequentially.

Events:

Events are wrapper around the delegate. It sits on top of the delegate and provides only the necessary encapsulation so that the destination objects can subscribe to the Event and not have full control on the delegate object.

Events are declared using delegates. The delegate object encapsulates a method so that it can be called anonymously. An event is a way for a class to allow clients to give it delegates to methods that should be called when the event occurs. When the event occurs, the delegate(s) given to it by its clients are invoked.
We will consider an example implementation of Logger application, which can be used to log messages in Console, File or Database etc.

We will declare a delegate named LogWriteDelegate which accepts one parameter named message.

public delegate void LogWriteDelegate(string message);

Next we will declare an Event of type LogWriteDelegate

public event LogWriteDelegate LogWriteEvent;

In our sample Logger the FileLogger and ConsoleLogger will subscribe or register to the above mentioned event so that when the Write method of logger is called the respective logic within the Write method of FileLogger and ConsolLogger will also gets invoked.

using (var logger = new Logger("testing", EntryType.Debug))
{
logger.LogWriteEvent += new Logger.LogWriteDelegate(consoleLogger.Write);
logger.LogWriteEvent += new Logger.LogWriteDelegate(fileLogger.Write);
logger.Write();
}

You can notice here a multicast delegate; the LogWriteEvent is being registered with Console and File log write methods.

While firing an Event within the Logger object, it is always a good practice to check whether the event is registered or not.

public void Write()
{
if (LogWriteEvent != null)
LogWriteEvent(ToString());
}

Here the LogWriteEvent holds the address of the methods console.Write and fileLogger.Write. When firing an event it will sequentially call the respective methods which are pre-registered to this Event.

Note: The Logger application is designed in such a way that in future you can have multiple implementations of Loggers. Right now we have Console and File Logger; if you are interested in implementing a Database logger we can create a new Class named DatabaseLogger which will implement ILogger interface. Provide necessary Write method logic so that it will log messages to database.

Ones you have done with the DatabaseLogger implementation, you just have to create an instance and register the event as we have done for Console and File Loggers.

Download Sample Logger Application

The post Delegate and Events in C# .NET first appeared on Student Projects.

AutoMapper is an object-object mapper. Object-object mapping works by transforming an input object of one type into an output object of a different type.

When to use Automapper?

Here is one Sample scenario. Assume we have a domain model say a Customer entity and we are planning to show a list of Customers in a UI, for that, we need a much lighter object say CustomerViewModel, which has a list of Customer objects that can be used to bind the controls in UI layer.

Would you like to have something that will do mapping from Customer to the CustomerViewModel automatically?

Of course, you do, especially if you have another situation like mapping of heavy data objects into DTO objects which are considered to be sent though the wire.

How do I use AutoMapper?

First, you need both a source and destination type to work with. The destination type’s design can be influenced by the layer in which it lives, but AutoMapper works best as long as the names of the members match up to the source type’s members. If you have a source member called “FirstName”, this will automatically be mapped to a destination member with the name “FirstName”.

Once you have your types, and a reference to AutoMapper, you can create a map for the two types.

Mapper.CreateMap<Order, OrderDto>();

The type on the left is the source type, and the type on the right is the destination type. To perform a mapping, use the Map method.

OrderDto dto = Mapper.Map<Order, OrderDto>(order);

AutoMapper also has non-generic versions of these methods, for those cases where you might not know the type at compile time.

Where do I configure AutoMapper?

If you’re using the static Mapper method, configuration only needs to happen once per AppDomain. That means the best place to put the configuration code is in application startup, such as the Global.asax file for ASP.NET applications. Typically, the configuration bootstrapper class is in its own class, and this bootstrapper class is called from the startup method.

Samples and DLL’s:

http://www.codeproject.com/KB/library/AutoMapper.aspx

http://automapper.codeplex.com/

The post Introduction to Automapper first appeared on Student Projects.

Introduction

3-Tier architecture generally contains User Interface (UI) or Presentation Layer, Business Access/Logic Layer (BAL) and Data Access Layer (DAL).

Presentation Layer (UI)
Presentation layer is responsible for displaying the views. Contains windows forms or ASP.NET pages, where data is presented to the user or input is taken from the user. We will consider a sample Windows form application which will show the Authors information and details in the UI.

Business Access Layer (BAL) or Business Logic Layer

BAL contains business logic, validations or calculations related with the data

Business Entities

Business entities are reusable entities developed as per the application. We are making use of these entities in BAL and DAL. The data access layer fetches the data and converts the data say to a List of business entity. Ex: When we are retrieving a list of Authors details, the DAL will fetch all the authors and returns List<AuthorsBE> list of author’s business entities.

Data Access Layer (DAL)

DAL contains methods that helps business layer to connect the data and perform required action, might be returning data or manipulating data (insert, update, delete etc). For this demo pubs sample application, the BAL makes a call to data access to get all the list of authors i.e GetAllAuthors(), to get all the list of author titles GetAuthorTitleDetails(string authorID)

Advantages of N-Tier Application

1. Decoupling the logic: By loose coupling the logics of Presentation, Business and Data access suppose if there is a change in the UI layer, you will only have to only about the modifications in the Presentation layer. Right now it is using SQL Server database so in future is there is a change in the database we will have to modify the logic with in the Data access layer and nothing else.
2. With layered architecture you can do the software development in Parallel. That means you can code each layers independently
3. Easy to Test: The testability of the software increases by decoupling the logics into multiple layers. You can independently Unit Test the logics of different layers
4. Reusability of Components

How to run the sample:

1. Download pubs database sample from http://www.microsoft.com/download/en/details.aspx?id=23654 link
2. Install the MSI: SQL2000SampleDb.msi , run the scripts to create Pubs database.
3. Download the sample project for this article from the below mentioned link for ‘Sample Project for Download’
4. Open SQL Management studio and execute the stored procedures with in the DataAccessLayer – > Scripts folder in Pubs database.
5. Open PubsSamplePresentation.sln Solution from VS 2010 or VS2011
6. Go to PubsSamplePresentation and open App.config
7. Change the connection string (PubsConnectionString) value appropriately
8. Run the Windows Form application – PubsSamplePresentation

Sample Project for Download: PubsSamplePresentation

The post 3-Tier Architecture in .NET first appeared on Student Projects.