問題タブ [micro-orm]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
11 に答える
25568 参照

visual-studio-2010 - Dapperを使用してデータベースからモデルを生成するには?

ぺたポコキャンプから来ました。PetaPoco には、データベースからモデルを生成する T4 テンプレートがあります。Dapper で利用できる同様のものはありますか?

NuGet を使用して Dapper をインストールし、SqlHelper.cs を追加しましたが、データベースからモデルを生成するものは見つかりませんでした。

0 投票する
1 に答える
537 参照

c# - 軽量の TransactionScope の実装

私はこのSOの質問を参照しています: Dapperを使用して予想よりも時間がかかる一括挿入

そして、その質問に対するこの@SamSaffronコメントに:

「TransactionScope は、一般的には気にしない DTC のナンセンスの束を処理します。その機能が必要でない限り回避します。スレッド ローカル ストレージに接続された独自のコンテキストをロールするのは非常に簡単です。」

変数にアタッチされたトランザクションを使用して独自の TransactionManager をロールする方法は知っていますが、コマンドがトランザクションを自動的に登録するようにエミュレートする[ThreadStatic]信頼できる方法はありますか? 最終的な製品は、MSDTC 配管のないトランザクション スコープになります。TransactionScope

0 投票する
2 に答える
423 参照

c# - マイクロオーム ツールはアプリケーション アーキテクチャのどこに配置されているか

「Select x,y,z From Customer」のような単純なステートメントは、データ アクセス層にあります。

特定の都市からの顧客のフィルタリングなどのロジックがクエリに含まれる場合、フィルタリングをビジネス レイヤーに配置し、メモリ内の顧客コレクションに対して実行する必要があります。

Micro ORM ツールについて考えると、次のようなロジックを含む SQL ステートメントが表示されることがよくあります。

このコード行をどこに置くべきですか? ビジネスレイヤーまたはデータアクセスレイヤーで?

ビジネスレイヤーに属する必要があるステートメント内にロジックがあります。しかし、それから私は持っています

BLL 内の Select ステートメント ??

これはすべて混乱しています。

0 投票する
1 に答える
632 参照

c#-3.0 - 3.5のdapperを使用した動的結果セット

事前に不明なフィールドを持つレコードセットを返すストアプロシージャ呼び出しがあります。相互運用上の理由から、3.5で動作させる必要があるため、動的なサポートはありません。dapperに組み込まれているソリューションはありますか?一人では見つかりませんでした。そのような解決策がない場合、フェッチするプロパティを公開するタイプをその場で作成することは理にかなっていますか(そしてそれは機能しますか)? 編集 私は、c#3.0で動的オブジェクトを作成することにより、(元のコードベースを微調整することなく)完全に外部のソリューションを追加することができました。 これが拡張dapperコード で、ここが動的オブジェクトのファクトリです

0 投票する
1 に答える
152 参照

c# - テーブルごとに 1 つのコード ファイルを生成するマイクロ ORM はどれですか

petapoco を使用しましたが、1 つのファイルですべてバンプします。

より多くの Rails の方法を実行できるようにしたい - クラスごとに 1 つのコード ファイルを生成する。

どうも。

0 投票する
3 に答える
2324 参照

asynchronous - ServiceStackおよびOrmLiteでの非同期サポート

現在、非同期サービスの作成を可能にするServiceStackの非同期ブランチが存在します。ただし、非同期のすべての利点を得るには、すべてのIOバウンド操作を非同期にする必要があるため、すべてのデータベース要求も非同期にする必要があります。現在、PostgresqlでOrmLiteを使用しています。したがって、OrmLiteが非同期クエリ/操作をサポートしているかどうかを知りたいですか?そうでない場合、他のどの.Net Micro-Ormsが非同期操作をサポートしますか?

0 投票する
1 に答える
4631 参照

dapper - Dapper.Net および Dapper.Net 拡張機能の「NotMapped」に相当するものはありますか?

私は Dapper.Net を使い始めて、今のところとても気に入っていますが、1 つの問題に遭遇しました。

次のような POCO クラスがあるとします。

ここで、Dapper.Net と Dapper.Net 拡張機能を使用して、次のようにして、そのデータ型のすべてのインスタンスを DB から単純にロードします。

これはLinqセットアップでは正常に機能しますが、評価を強制する.ToList()のある行に到達すると、FullNameで「無効な列名」が発生します。NotMapped の Entity Framework DataAnnotations を尊重する可能性があると考えて、NotMapped 属性を追加してみました (プロジェクトに EF 5 を追加した後)。これはうまくいきませんでした。

問題は、列が DB から期待されないことを Dapper.Net にどのように伝えるかということです。これは、モデル POCO で表示されるすべての DB 列をマップしようとしている拡張機能の問題ですか? SQL の記述に戻り、必要な列のみを明示的に要求する必要がありますか、または列で NotMapped と同等のものを取得する方法はありますか?

0 投票する
2 に答える
4476 参照

c# - Dapper拡張機能を使用したSQLのカスタマイズ

私はいくつかのタイプにDapperExtensionsを使用していますが、ほとんどのユースケースで非常にうまく機能します。私は多対多の関係を持っているケースに遭遇しました、そして私は次のようなことをしたいです:-

明らかに、DapperExtensionsは「SELECTid、a、b、c FROM Foo」を処理できますが、後者の部分は処理できません。選択して必要なFooIDのリストを取得し、それをDapper Extensionsに渡すこともできますが、効率は低下します。

プレーンなDapperで実行できない部分は、SELECT列リストを自動的に取得することです。したがって、私が本当に望んでいるのは、次の方法です。-

  • DapperExtensionの内部メカニズムからSELECT列リストを取得します
  • DapperExtensionの内部メカニズムから基本的な「SELECTid、a、b、cFROMFoo」を取得します
  • Hook Dapper ExtensionsカスタムWHERE句を追加できるように、コードを取得します

私はコードを見ましたが、これらのことを行う方法を見つけることができません。誰か助けてもらえますか?現時点では、プレーンなDapperと「SELECT * ...」を使用して回避しましたが、もっと良い方法があると確信しています。

0 投票する
2 に答える
1800 参照

c# - Visual Studio の Intellisense を使用した Simple.Data Micro ORM (ダイナミクス)

Simple.Data Micro ORMを使用することにしました。データベースを操作するのが簡単で、かなり多くのコードを書く必要がなく、ダイナミクスのためにオブジェクトを作成する必要さえありません!

問題は、Visual Studio で Intellisense のサポートが失われていることです。コードを記述するたびに行名を確認するのは好きではありません。パッチのような方法でも、ダイナミクスでインテリセンスを利用する方法はありますか?

それで彼らは、何らかの方法でダイナミクスを備えたインテリセンスを持つことが可能かどうか疑問に思うかもしれません.

0 投票する
3 に答える
609 参照

asp.net - Simple.Data デフォルトで生成されるクエリとパフォーマンス

ASP.NET 4.5 Web サイトに Simple.Data Micro-ORM を使用することを考えています。ただし、使用するかどうかを決定する前に知っておく必要があることがあります。

たとえば、次の Join クエリを見てみましょう。

このクエリは次のように変換されます。

「Genres」テーブルが、数千または数百万の行を持つテーブルであると仮定しましょう。JOIN が行われた後にデータをフィルター処理するのは非常に非効率的である可能性があると思います。これは、このクエリが Simple.Date で変換したものです。

Generes テーブルで最初にデータをフィルター処理する方がよいでしょうか。つまり、最初に SELECT ステートメントを作成し、そのフィルター処理されたテーブルで JOIN を作成しますか?

事前にデータをフィルタリングした方がよいのではないでしょうか?

さらに、Simple.Data を使用してそのタイプの複雑な (フィルター処理されたテーブルでの結合) クエリを作成するオプションはありますか。

Simple.Data を続行するか、別のマイクロ ORM を優先してダンプするかを知るには、回答が必要です。