VS - VS 2010 Database Project: An Introduction

Visual Studio 2010 has a new Database Project. The scripts in this new Database project define your database just like the files in your code projects define your application.

The prior Database project (the one under the "Other Projects" node in VS 2003/2005/2008 as detailed in this prior post), was simply a storage container for your database scripts.

The new Database project is alive. Like the old Database project, it retains your database scripts, but it also has Intellisense, build-time validation, and automatic deployment features. It allows you to keep the definition of the database in your scripts and ensure that the scripts are deployed to your development database.

This is the first in a series of posts on using the new Database project. This post provides the steps for adding a Database Project to any solution in either VB or C#.

1. Right-click on your solution and select Add | New Project. Or select File | New Project from the main menu.

The Add New Project dialog is then displayed.

2. Open the Database node in the Installed Templates panel on the left and select SQL Server.

3. Select SQL Server 2008 Database Project from the middle panel, enter a name for the project, and click OK.

NOTE: If you have SQL Server 2005, you can select the SQL Server 2005 Database Project instead.

Visual Studio then creates the new project and adds it to your Solution Explorer:

4. Use the Database project to write the scripts for a new database or manage the scripts for an existing database.

For example, use the Tables node to manage your table scripts and the Programmability | Stored Procedures node to manage your stored procedure scripts:

SQL - Last Access date of Databases

To know the last accessed date of Database run the following query

SELECT DatabaseName, MAX(LastAccessDate) LastAccessDate

FROM

    (SELECT

        DB_NAME(database_id) DatabaseName

        , last_user_seek

        , last_user_scan

        , last_user_lookup

        , last_user_update

    FROM sys.dm_db_index_usage_stats) AS PivotTable

UNPIVOT 

    (LastAccessDate FOR last_user_access IN

        (last_user_seek

        , last_user_scan

        , last_user_lookup

        , last_user_update)

    ) AS UnpivotTable

GROUP BY DatabaseName

HAVING DatabaseName NOT IN ('master', 'tempdb', 'model', 'msdb')

ORDER BY 2

OOPS - SOLID Principles of OOD

Dependency Management is an issue that most of us have faced. Whenever we bring up on our screens a nasty batch of tangled legacy code, we are experiencing the results of poor dependency management. Poor dependency managment leads to code that is hard to change, fragile, and non-reusable. Indeed, I talk about several different design smells in the PPP book, all relating to dependency management. On the other hand, when dependencies are well managed, the code remains flexible, robust, and reusable. So dependency management, and therefore these principles, are at the foudation of the -ilities that software developers desire.

The first five principles are principles of class design. They are:

SRP	The Single Responsibility Principle	A class should have one, and only one, reason to change.
OCP	The Open Closed Principle	You should be able to extend a classes behavior, without modifying it.
LSP	The Liskov Substitution Principle	Derived classes must be substitutable for their base classes.
ISP	The Interface Segregation Principle	Make fine grained interfaces that are client specific.
DIP	The Dependency Inversion Principle	Depend on abstractions, not on concretions.

The next six principles are about packages. In this context a package is a binary deliverable like a .jar file, or a dll as opposed to a namespace like a java package or a C++ namespace.

The first three package principles are about package cohesion, they tell us what to put inside packages:

REP	The Release Reuse Equivalency Principle	The granule of reuse is the granule of release.
CCP	The Common Closure Principle	Classes that change together are packaged together.
CRP	The Common Reuse Principle	Classes that are used together are packaged together.

The last three principles are about the couplings between packages, and talk about metrics that evaluate the package structure of a system.

ADP	The Acyclic Dependencies Principle	The dependency graph of packages must have no cycles.
SDP	The Stable Dependencies Principle	Depend in the direction of stability.
SAP	The Stable Abstractions Principle	Abstractness increases with stability.

C# - Composition over Inheritance

We had often heard that composition is better than inheritance. Why is it so? First of all how is one different from the other and what are the similarities in them?

Lets say we are writing simulation software for Rocket Launching systems which are to be supplied to different countries. Now these different countries can use them as they want it.
The code for our launching system is below:

public class Launcher{
    public bool LaunchMissile()
    {
        Console.WriteLine("Missile launched");
        return true;
    }
}

public class SufraceToAirMissileLauncher:Launcher{

 }

Now, country A uses this code to launch missile as follows:

static void Main(string[] args)
    {
        SufraceToAirMissileLauncher staLauncher = new SufraceToAirMissileLauncher();
        bool isLaunched =   staLauncher.LaunchMissile();    

}

This is how Inheritance is used. The various launchers can reuse the base Launcher class code to launch missile.

The same thing can be achieved by using Composition where base class functionality is encapsulated inside the main concrete class. The code for that is below:

public class SufraceToAirMissileLauncher{
    private Launcher launcher = new Launcher();
    public bool LaunchMissile()
    {
        return launcher.LaunchMissile();
    }

}

The client UI code remains the same.

Now due to our superb code, our patented launching software had become famous and another country B wants to use it. But they had a condition that instead of launching the missile through base class they would want to get an instance of a missile. Now it's up to them what they want to do with it. They might add some nuclear material on it or modify it to increase its range or do whatever they might like. So another Missile object comes into the picture.

public class Missile{
    private bool isLaunched;
    public bool IsLaunched
    {
        get { return isLaunched; }
        set { isLaunched = value; }
    }
    public Missile(bool isLaunched)
    {
        IsLaunched = IsLaunched;
    }

}

And the base class function has changed to:

public class Launcher{
    public Missile LaunchMissile()
    {
        Console.WriteLine("Missile returned");
        return new Missile(true);
    }

}

Now it returns a missile instead of launching it. So now if we rely on inheritance, the client code of country A would break since the method signature has changed from what is being used in its UI.

However, if the country A had used composition instead, the code will not break. Only the derived class function would need to accommodate the new changed behavior of the base class. To accommodate this, we need to change our derived class code function "LaunchMissile" as:

public class SufraceToAirMissileLauncher{
    private Launcher launcher = new Launcher();
    public bool LaunchMissile()
    {
        Missile missile = launcher.LaunchMissile();
        return missile.IsLaunched;
    }

}

Hence, the client code of country A would still work:

static void Main(string[] args)
    {
        SufraceToAirMissileLauncher staLauncher = new SufraceToAirMissileLauncher();
        bool isLaunched =   staLauncher.LaunchMissile();   

 }

On the other hand country B which was insisting on getting a missile would still get missile from the base class.

So through this simple example we see how the composition is favored over inheritance to maintain compatibility and where there is a possibility that the functionality might change in future.