Domaを参考に作るSQL中心の.NET用Daoフレームワーク

Soma .NET

Domaを作った経験をベースにしつつあんまりDomaの実装にとらわれない形で作っていこうと思います。（ただし、API的にはあんまり違いはないと思います。基本的にDaoを介して、検索系はSQLファイルにマッピングし、更新系はデフォルトで自動生成になります。）
名前はSomaにしました。とりあえず、codeplexに公開しています。

コードはコミットしてあるけど、まだプロトタイプみたいなものです。ぜんぜんできていません。

Domaでは避けたAOPですが、aptに変わるものとしてPostSharpを使おうかなーと検討中です。PostSharpは、実行時ではなくコンパイル時にコードをエンハンスするライブラリです。で、その際にコードをバリデーションできるので、Domaのように規約から外れたコードをチェックしてコンパイルのフェーズでエラーにできます。軽く試した感じだととても簡単に使えました。ドキュメントが比較的豊富でいい感じです。

課題は、ライセンスかな。軽く見た感じではCommunity Editionを使うのに問題はなさそうですが。まだちゃんと読んでいません。

あと、virtualなメンバをインターセプトできない、コードを吐けない、といった制限があるのでDaoがDomaとは違った形になりそうです。どういうことかというと、たとえば、次のように空のbodyを持たないといけないかも。

[Dao]
public class EmployeeDao 
{
    [Select]
    public Employee SelectById(int id)
    {
        return null;
    }
}

DomaではメタクラスをつくってEntityやDomainのメタ情報をもっていましたが、PostSharpを使うとアトリビュートにそのような情報をキャッシュしておけるのでメタクラスみたいのはいらなさそうです。

SQLコメントに埋め込む式言語は、System.Linq.Expressions名前空間のクラスを使って実装するつもりです。Domaでは、全部自分でがんばりましたが、System.Linq.Expressionsを使うとずいぶん楽ができます。この辺はある程度作ってみて実感できました。

EntityListenerはコンテキストを渡せるようにするかもしれません。これは、なぜかというと、場合によってはメソッド名で条件分岐したいことがあるからです。contextにメソッド名やカスタムアトリビュートの情報を持たせて論理削除するとか。

public interface EntityListener<TEntity> 
{
    
    void preUpdate(UpdateContext context, TEntity entity);
    ...
}