My Queryクラス。あなたの意見？

Question

このQueryクラスを共有して、それについて考えてみたいです。 Queryクラスは、dbconnectionに対してクエリを実行するのに役立ちます。私は実装を含めていませんが、投稿するのはちょっとです。ここでは例の呼び出しだ、あなたのアイデアを得るでしょう：

• ADO.NETコマンドコードを記述する必要はありません：

  OrdersDataTable table = 
      new Query(connection) 
      .Table("Orders") 
      .Fields("OrderID,CustomerID,Description,Amount") 
      .GreaterThan("OrderID", 1000) 
      .OrderBy("OrderID") 
      .Execute<OrdersDataTable>(); 
  

  ここで私はクラスを好きな理由です。このクラスを呼び出すと、ADO.NET equivilentより少ない行しか使用できません。

• 各メンバー関数はこれを返し、複数の呼び出しを一緒にチェーンすることができます。このパターンの名前があるかどうかはわかりません。あなたは知っていますか？
• MySql、OleDb、およびSqlServerの各方言を処理します。
• ADO.NETのequivilentよりも読みやすいと思われます。
• 呼び出しの順序は関係ありません。すべてのパラメータは内部コレクションにバッファされ、Executeが呼び出されると読み込まれます。
• 私のシナリオでは、複数のデータベース製品と通信する必要があります。そのため、一度だけ一般的な方法でクエリを作成し、所定の接続を渡したいとします。ストアドプロシージャのようなDB固有の機能を活用するのは大変な問題です。

私は、このクラスを内部的に使用するDALを持っています。 UIは、いくつかのクエリパラメータを渡してDALを呼び出し、DataTableが返されます。このクラスは、DAL実装のLOCを大幅に削減するとともに、読みやすくしました。

OrdersDataTable orders = Orders.GetByOrderId(1) 

とのimpl：

public static OrdersDataTable GetByOrderId(int id) 
{ 
    return 
     new Query(connection) 
     .Table("Orders") 
     .Fields("OrderID,CustomerID,Description,Amount") 
     .Equals("OrderID", id) 
     .Execute<OrdersDataTable>(); 
} 

おかげ

ここではサンプルDALコールがあります！

編集：すばらしいフィードバックをいただきありがとうございます。皆さんの多くがLinqToSqlを提案しました。 Microsoftは現在SQL Serverのみをサポートしているため、私はLinqを選択しませんでした。私は、Jet、MySqlとSQL Serverのテーブルを照会する必要があります。

誰かがAND句とOR句をどのように構築するか尋ねました。ここではそれはあなたがとても素敵な小さなORMを書いているように見える各

//and example 
    public static OrdersDataTable GetByOrderIdAndCustomerId(int orderId, int customerId) 
    { 
     return 
      new Query(connection) 
      .Table("Orders") 
      .Fields("OrderID,CustomerID,Description,Amount") 
      .Equals("OrderID", orderId) 
      .Equals("CustomerID", customerId) 
      .Execute<OrdersDataTable>(); 
    } 

//or example 
    public static OrdersDataTable GetByOrderIdOrCustomerId(int orderId, int customerId) 
    { 
     return 
      new Query(connection) 
      .Table("Orders") 
      .Fields("OrderID,CustomerID,Description,Amount") 
      .OrBegin 
      .Equals("OrderID", orderId) 
      .Equals("CustomerID", customerId) 
      .OrEnd 
      .Execute<OrdersDataTable>(); 
    } 

Answer 1

の例は、リポジトリ（または近い）パターンの実装と（オブジェクトリレーショナルマッパー）。 Fluent Interfacesというデザインパターンを活用しました.Table .Fieldsは互いにカスケードしています。

これら3つのパターンはすべて、LOCを大幅に削減し、メンテナンス性を向上させ、テスト能力を大幅に向上させることがわかっているので、現代のソフトウェアシステム設計に含まれることは非常に良いです。ジェネリックスを使って強く型付けされたオブジェクトを正しく返すことができるように、あなたの機能を構築したことも好きです。

編集：私は改善のために見ることができる唯一可能な領域はすべての呼び出しは、新しいクエリで、おそらく正しいプロバイダを注入し、対象になる依存性注入フレームワークを使用するようにコードを変更するという事実を変えることへの希望クエリに対してデータベーストランザクションを開始すると呼ばれます。あなたのコードがすでに「Poor man's dependency injection」と呼ばれるQueryクラスの内部でコードを実行しているのであれば、それは非常によく似ています（あなたの実装に依存します）。それが既にあなたのために働いていて、あなたのデータベースサポートのタイプを貧しい人のDIはちょうどいいはずです。私は、DIフレームワークが緩和するコード結合のレベルが高くなる（または、隠蔽する方法が悪い悪い設計決定である）ため、新しいキーワードのファンではありません。

Markの回答に対する回答として、私は通常、コード生成のファンではありません。常に問題のポイントになるようですが、関与する魔法の文字列の量を減らすための非常に良い点があります。私の代わりにかかわらず、これを処理するためにラムダ演算子と式を使用することを選ぶだろう、あなたは、これが達成できる：

public static OrdersDataTable GetByOrderId(int id) 
{ 
    return 
     new Query(connection) 
     .Table(x => Inflector.Pluralize(x.GetType()) 
     .Fields(x=> { x.OrderID, x.CustomerID, x.Description, x.Amount }) 
     .Equals(x=>x.OrderID, id) 
     .Execute<OrdersDataTable>(); 
} 

これは、あなたが活用できるようにする魔法の文字列リファクタリングの問題のすべてを削除しますMicrosoftのリファクタリングツールはるかに簡単に構築されましたResharper（もちろん、Resharperはリファクタリング中に魔法の文字列を見つけることができます）。

Inflectorは、テキストを処理する機能を含む無料のライブラリ（OSSであるかどうかを覚えていない）で、Pluralizeメソッドは単語を取り、それを複数のものにします。これは、Storyが正しくなく、Inflectorが正しく "Stories"を返すため、GetType（）+ "s"に行くことができないStoryがある場合に便利です。

Answer 2

私は通常、これらの機能的なやり方から離れようとします。問題が発生したときに問題を突き止めるのは時々混乱することがあります。

私はちょうどLINQを使用し、より読みやすいコードで同じタスクを達成します。

Answer 3

私はLinqがこれを行うように設計されていることに同意しますが、あなたの要件に合っていれば独自のアーキテクチャーを構築しない理由はありません。

もう少し進んで、列挙型や他のオブジェクトベースのエンティティを構築してリテラルテキストの必要性を減らすためにコード生成を使用します。

Answer 4

これは楽しい演習です。コードはかなり読みやすく簡潔であるようです。実稼働環境では、深刻な必要がなければ、私はおそらく車輪の再発明から離れています。 LINQやNHibernateなどの他のバトルテスト済みのパッケージでは、「無料」で入手できるカスタムORMに機能を追加するのではなく、自分の時間と、あなたのものがアプリケーションで価値を生み出すために費やされるほうがよいでしょう。