必要に応じて毎回書いていたのですが、面倒なのでメモしておくことにします。
まずは、次のようなメソッドにして算出する場合です。

int GetAge(DateTime birthday, DateTime? baseday = null) {
    var b = baseday ?? DateTime.Today; // 第2引数省略時はシステム日付時点の年齢を返す
    return (getNum(b) - getNum(birthday)) / 10000;
    int getNum(DateTime d) => d.Year * 10000 + d.Month * 100 + d.Day;
}

処理内容は単純で、二つの年月日を数値化して差を求めて 10000 で割った商を年齢として返しているだけです。
なぜ 10000 で割るのかというと、たとえば「1987年1月23日」なら 19870123 という数値になっているため、10000 で割ることで「年」の部分が取り出せるからです。
なお、getNum はローカル関数で、この機能は C#7 以降のみ対応です。

たとえば、以下のように使います。

var birthday = new DateTime(1989, 12, 1); // 誕生日
var age = GetAge(birthday); // 今日時点の年齢

必要に応じて計算したい場合は、以下のようにワンライナーで書くこともできます。

var age = ((t.Year * 10000 + t.Month * 100 + t.Day) - (b.Year * 10000 + b.Month * 100 + b.Day)) / 10000;

この方が高速ですし、わかりやすいかもしれません。

DateTime 型のプロパティ Date を実装した例です。
C#7 からは、以下のようなパターンで記述することが多くなりそうです。

public DateTime Date => 
    DateTime.TryParseExact(
	"20170123", 
	"yyyyMMdd", 
	CultureInfo.CurrentCulture, 
	DateTimeStyles.None, 
	out DateTime result) ? 
	    result : 
	    DateTime.Today;

文字列で表現された日付(時刻)が正しく DateTime 型に変換できた場合は、変換した結果の result の値を返します。
そうでなければ今日の日付を返します。

参考までに、以下のような書き方もできます。

public DateTime Date { 
    get {
        DateTime result;
        if (DateTime.TryParseExact(
            "20170123", 
	    "yyyyMMdd", 
	    CultureInfo.CurrentCulture, 
	    DateTimeStyles.None, 
	    out result)
        {
            return result;
        } 
	return DateTime.Today;
    }
}

なるべく式で書いた方が良いので、私は前者の書き方ですね。

C#7 からローカル関数が使えるようになりました。
今までは、ひとつのメソッドが長くなりすぎた場合に、可読性を向上させる目的で下請けメソッドを宣言していました。

int Method() {
　　　　：
    Shitauke();
　　　　：
}

int Shitauke() {
    :
    :
}

ローカル関数を使うと、以下のように書くことができます。

int Method() {
    int Shitauke() {
        :
        :
    }
    :
    Shitauke();
    :
}

これによって、気軽に自身のメソッドブロック内に独立性の高い処理をメソッドアウトできるので、他のメソッドに干渉されることなく関連性の高いメソッドをまとめて読めるので積極的に使っています。
ただし、メソッドブロック内のコードの可読性が落ちます。
特に、ローカル関数の宣言部分と、メソッドのメインコードの区別がつかないところが悩ましいです。
いろいろ試してみた結果、次のように落ち着きました。

1. ローカル関数名はキャメル表記にする
2. ローカル関数の宣言はメソッドブロックの最後にまとめる
3. そのメソッドの主処理の末尾に return ステートメントを記述する

ローカル関数名をキャメル表記にするのは、主処理が関数を呼び出すとき、他で宣言されているものかローカル関数かを明確にできるためです。
ローカル関数の宣言を最後にまとめる理由ですが、先頭にまとめると主処理がどこから開始されるのかを探さなければならないからです。
主処理の最後に return を記述する必要は本来はないのですが、これもどこまでが主処理の最後なのかを明確にするためです。

int Method() {
    :
    shitauke();
    :
    return;

    int shitauke() { // ローカル関数名はキャメル表記にする。
        :
        :
    }
}

ただし、これが正解かというと、いろいろな意見もありそうです。
とりあえず、しばらくは上記の規則いこうかと思います。

先ほど軽くはまったのでメモです。

次のコードは、正しく動作しません。

IEnumerable GetItems(){
    using (var db = CreateDataContext()) {
        return db.Table;
    }
}

void Main(){
    var items = GetItems();
    foreach(var x in items) {
        Console.WriteLine(x.Title);
    }
}

理由です。
db.Table に実際にアクセスされるのは、Main メソッドの foreach で items を使用した時点ですが、この時すでに DataContext インスタンスが破棄されているためデータベースにアクセスできずにエラーが発生します。

もう少し詳しく説明すると、GetItems メソッドが return している db.Table は IQueryable型です。
これは、データベースへのアクセスに関する定義を返すだけで、実際に取得したコレクションインスタンスを格納している訳ではありません。
一方 IQueryable 型は IEnumerable 型を継承しているため、GetItems メソッドのように暗黙の型変換が実行されています。
ここに気づかないとはまる訳です。
GetItems メソッドを以下のようにすると、正しく動作するようになります。

using (var db = CreateDataContext()) {
    return db.Table.ToList(); // ←変更
}

理由は、ToList メソッドで取得したデータからコレクションインスタンスを生成したものを返すためです。
簡単な理由ですが、実際の開発コードでは、複雑にメソッドが絡み合っていたりするので、軽くはまるのでメモしておきます。

以下のように名前を明確に示したいデリゲートがあったとします。

public delegate int HogeHoge(int value1, int value2);

今、次のような書き方を思いつきました。

    
using HogeHoge = Func<int, int, int>;

delegate を使って正しく宣言するか、using ディレクティブを使って別名で宣言するかの違いなんですけどね。
メモしておきます。