タグ付けされた質問 「orm」

ORMとその長所と短所について同僚と非常に刺激的で興味深い議論をしました。私の意見では、ORMは非常にまれな場合にのみ役立ちます。少なくとも私の経験では。 しかし、現時点では自分の主張をリストしたくありません。それでは、ORMについてどう思いますか？長所と短所は何ですか？

58 object-oriented  design-patterns  orm  anti-patterns 

私は、1000以上のテーブル、さらに数百のビュー、数千のストアドプロシージャを備えたSQL Serverデータベースを使用しています。新しいプロジェクトにEntity Frameworkの使用を開始したいと考えており、そのための戦略に取り組んでいます。ハングアップしているのは、テーブルを異なるモデルに分割する最良の方法です（最初にコードを作成する場合は、EDMXまたはDbContext）。私はすぐにいくつかの戦略を考えることができます： スキーマによる分割 テーブルはおそらく12個のスキーマに分割されています。スキーマごとに1つのモデルを作成できます。ただし、dboは500を超えるテーブル/ビューで非常に大きくなるため、これは完全ではありません。もう1つの問題は、特定の作業単位が複数のモデルにまたがるトランザクションを実行しなければならないことです。これにより、EFがこれをかなり簡単にすると仮定します。 意図 で分割するスキーマを気にする代わりに、モデルを意図で分割します。そのため、取得する粒度に応じて、アプリケーション、プロジェクト、モジュール、または画面ごとに異なるモデルを用意します。これに伴う問題は、UserやAuditHistoryなど、すべての場合に必ず使用する必要がある特定のテーブルがあることです。それらをすべてのモデルに追加しますか（DRYに違反すると思います）、それともすべてのプロジェクトで使用される別のモデルにありますか？ まったく分割しないでください-1つの巨大なモデル これは開発の観点からは明らかにシンプルですが、私の研究と直感から、設計時、コンパイル時、そしておそらく実行時の両方でひどく実行できるようです。 このような大規模なデータベースに対してEFを使用するためのベストプラクティスは何ですか？具体的には、この大量のDBオブジェクトに対してモデルを設計する際にどのような戦略を使用しますか 私が上で持っているものよりもうまく機能すると思っていないオプションはありますか？ また、これはNHibernateなどの他のORMの問題ですか？もしそうなら、彼らはEFよりも優れたソリューションを考え出しましたか？

50 entity-framework  orm  enterprise-architecture 

私はSQLに真剣な経験はなく、LINQの代わりにSQLを書くことさえ嫌いです。ORMには十分満足しています。 雇用主とセクターの観点から、SQLを知ることは重要ですか？習得する必要がありますか？ORMフレームワークよりも純粋なSQLを好む企業は、プログラミングの世界で「恐竜」ですか？

50 sql  orm  entity-framework 

私は自分でいくつかの研究を行い、基本的な概念を理解しました。しかし、いくつかの洞察は、実際の経験を通してしか得られません。 新しいフレームワークを学ぶ価値があるmyBatisの利点は何ですか？ どのような場合に使用を避けますか？

33 orm  database-development  hibernate 

2つのクラスがある： public class Parent { public int Id { get; set; } public int ChildId { get; set; } } public class Child { ... } 割り当てるときChildIdにParent、それが例外をスローするDB用DBまたは待機中に存在する場合、私が最初に確認する必要がありますか？ 例（Entity Framework Coreを使用）： 注：これらの種類のチェックは、Microsoftの公式ドキュメントでもインターネット全体で行われます：https : //docs.microsoft.com/en-us/aspnet/mvc/overview/getting-started/getting-started-with-ef-using- mvc / handling-concurrency-with-the-entity-framework-in-an-asp-mvc-application＃modify-the-department-controllerしかし、追加の例外処理がありますSaveChanges また、このチェックの主な目的は、APIのユーザーにわかりやすいメッセージと既知のHTTPステータスを返すことであり、データベースの例外を完全に無視することではないことに注意してください。そして、例外がスローされる唯一の場所は、内部にあるSaveChangesかSaveChangesAsyncを呼び出すときに例外がありません...コールFindAsyncまたはAny。そのため、子が存在するが以前に削除されていた場合SaveChangesAsync、同時実行例外がスローされます。 これは、foreign key violation「ID {parent.ChildId}の子が見つかりませんでした」と表示するために、例外の書式設定がはるかに困難になるという事実のために行いました。 public async Task<ActionResult<Parent>> CreateParent(Parent parent) { // is this …

32 c#  entity-framework  orm  web-api  asp.net-core 

現在作成しているアプリケーションは、ストアドプロシージャと手作りのクラスモデルを使用してデータベースオブジェクトを表現しています。一部の人々はEntity Frameworkの使用を提案しており、私はプロジェクトにそれほど遠くないので、それに切り替えることを検討しています。私の問題は、EFを主張する人々が悪い面ではなく、良い面だけを教えてくれると感じていることです:) 私の主な懸念は次のとおりです。 DataAnnotationsを使用してクライアント側の検証が必要であり、とにかくクライアント側のモデルを作成する必要があるように思えるので、EFがそのようなコーディング時間を節約するかどうかはわかりません ネットワークを経由するときにクラスをできる限り小さくしたいのですが、EFを使用すると、多くの場合、不要な追加データが含まれることがあります 複数のデータベースにまたがる複雑なデータベースレイヤーがあり、EFがこれを処理できるかどうかはわかりません。ユーザー、ステータスコード、タイプなどを含む共通データベースと、アプリケーションの異なるインスタンス用のメインデータベースの複数のインスタンスがあります。SELECTクエリは、データベースのすべてのインスタンスに対してクエリを実行できますが、ユーザーは、現在作業しているデータベース内のオブジェクトのみを変更できます。アプリケーションをリロードせずにデータベースを切り替えることができます。 オブジェクトモードは非常に複雑で、多くの場合、多くの結合が関係します EFの引数は次のとおりです。 並行性。各保存の前にレコードが更新されたかどうかを確認するためにチェックをコーディングする必要はありません。 コード生成。EFは私のために部分クラスモデルとPOCOを生成できますが、検証といくつかのカスタム解析メソッドのためにクライアント側モデルを作成する必要があると思うので、これは本当に多くの時間を節約するだろうと確信しています。 すべてのデータベースオブジェクトに対してCRUDストアドプロシージャを作成する必要がないため、開発の速度 現在のアーキテクチャは、パラメーター化されたストアドプロシージャを介してデータベース呼び出しを処理するWPFサービス、WCFサービスとWPFクライアントとの間でやり取りされるPOCOオブジェクト、および検証のためにPOCOをクラスモデルに変換するWPFデスクトップクライアントで構成されますデータバインディング。 私の質問は、EFはこれに適していますか？EFについて私が知らない落とし穴はありますか？

31 architecture  orm  entity-framework 

私は、すべてのデータアクセスにストアドプロシージャのみを使用している会社で働いています。そのため、新しいプロシージャを実行する必要があるコミットごとにローカルデータベースの同期を維持するのは非常に面倒です。私は過去にいくつかの基本的なORMを使用しましたが、この経験ははるかに優れており、よりクリーンです。今後の開発のために何らかのORMを使用することを検討していることを開発マネージャーとチームの残りに提案したいと思います（チームの残りはストアドプロシージャに精通しており、他のことは一度も使用していません）。現在のアーキテクチャは、.NET 1.1のように記述された.NET 3.5です。ActiveRecordの奇妙な実装を使用し、コードビハインドファイルでループされる型指定のないDataSetを返す「ゴッドクラス」を使用します。クラスは次のように機能します。 class Foo { public bool LoadFoo() { bool blnResult = false; if (this.FooID == 0) { throw new Exception("FooID must be set before calling this method."); } DataSet ds = // ... call to Sproc if (ds.Tables[0].Rows.Count > 0) { foo.FooName = ds.Tables[0].Rows[0]["FooName"].ToString(); // other properties set …

31 c#  database  orm  stored-procedures 

Doctrine 2（またはそれ以降）およびPropel 1.5（またはそれ以降）を使用したことがある人からの話を聞きたいです。これら2つのオブジェクトリレーショナルマッパーのほとんどの比較は古いバージョン（Doctrine 1とPropel 1.3 / 1.4に基づいています）に基づいており、両方のORMは最近のリビジョンで大幅に再設計されました。たとえば、Propelの批判のほとんどは「ModelName Peer」クラスにしているようです。これらのクラスはいずれの場合も1.5で廃止されます。 ここに私がこれまでに蓄積したものがあります（そして、私はこのリストをできるだけバランスの取れたものにしようとしました...）： 推進 長所 PHPのマジックメソッドに依存するのではなく、実際のコードが生成されるため、IDEに非常に優しい。これは、コード補完などのIDE機能を意味しますなどのが実際に役立つます。 高速（データベースの使用に関しては、データベースでランタイムのイントロスペクションは行われません） スキーマバージョン間のクリーンな移行（少なくとも1.6ベータ） PHP 5.3モデル（名前空間）を生成できます useXxxメソッドのようなものを使用して、多くのことを単一のデータベースクエリに簡単に連結できます。（上記の「コード補完」ビデオを参照） 短所 追加のビルドステップ、つまりモデルクラスのビルドが必要です。 生成されたコードは、Propelのバージョンが変更されたり、設定が変更されたり、スキーマが変更されるたびに再構築する必要があります。これは一部には直観的ではなく、モデルに適用されたカスタムメソッドは失われます。（おもう？） -真実ではない; 生成されたクラスは基本クラスであるため、カスタムメソッドは失われません。Propelは拡張専用のエンティティクラスを提供します。 いくつかの便利な機能（バージョンの動作、スキーマの移行など）はベータ版です。 教義 長所 もっと人気 Doctrine Query Languageは、PropelのActiveRecord戦略で簡単に可能なものよりも潜在的に複雑なデータ間の関係を表現できます。 Propelと比較した場合、再利用可能な動作を追加するのが簡単です。 スキーマを構築するためのDocBlockベースのコメントは、個別のXMLファイルではなく、実際のP​​HPに埋め込まれます。 どこでもPHP 5.3名前空間を使用します 短所 まったく新しいプログラミング言語（Doctrine Query Language）を学ぶ必要があります いくつかの場所で「マジックメソッド」の観点から実装されており、IDEのオートコンプリートは価値がありません。 データベースのイントロスペクションが必要なため、デフォルトではPropelよりもわずかに遅くなります。キャッシングはこれを削除できますが、キャッシングはかなり複雑になります。 コアコードベースに含まれる動作が少なくなります。Propelが提供するいくつかの機能（ネストされたセットなど）は、拡張機能を介してのみ使用できます。 Freakin 'HUGE :) これは、両方のツールで利用可能なドキュメントを読むことによってのみ収集しましたが、実際にはまだ何も作成していません。 ただし、両方のツールを使用して、各ライブラリの長所/短所に関する経験を共有し、この時点での推奨事項を共有している人からの意見を聞きたいと思います。

30 php  orm  doctrine 

ORMの評価を検討しています。 私が使ってきた亜音速、LINQのツーSQLやEntity Frameworkのを。私は、ジュニアからシニアまでの開発者のチームを持っています。 ORM for.NETを評価するための基準は何ですか？

30 .net  orm 

Android開発でORMを使用するのは理にかなっていますか、それともUIとDBレイヤー間のより緊密な結合のためにフレームワークが最適化されていますか？ 背景：Androidの開発を始めたばかりで、最初の本能（.netの背景から来た）は、小さなオブジェクトリレーショナルマッパーや、ボイラープレートの負荷を減らすのに役立つ他のツール（POJO + OrmLite + Lombokなど）を探すことでした。 しかし、最初のおもちゃのアプリケーションを開発しているときに、データベースカーソルを明示的に必要とするUIクラスを見つけましたAlphabetIndexer。AndroidライブラリがUIとDBレイヤーの厳密な分離に適していないのではないかと疑問に思い、どこでもPOJOを使用しようとすると（データベースへの直接アクセスの代わりに）便利で時間を節約できる多くの機能を見逃してしまいます）。 明確化：ORM を一般的に使用する利点を非常によく知っています。AndroidクラスライブラリがORM と共にどの程度うまく機能するかに特に興味があります。

27 android  orm  layers  android-development 

これは少し自由な質問ですが、インラインSQLスクリプトが標準である世界で育ったので、私はいくつかの意見が欲しかったので、SQLインジェクションに基づく問題と、SQLがどれほど脆弱であるかをすべて非常に認識しましたあらゆる場所で文字列操作を行います。 次に、クエリをORMに説明し、独自のSQLを生成させるORMの夜明けが来ました。多くの場合、これは最適ではありませんが、安全で簡単です。ORMまたはデータベース抽象化レイヤーのもう1つの良い点は、SQLがデータベースエンジンを念頭に置いて生成されたため、Hibernate / NhibernateをMSSQL、MYSQLで使用でき、コードが変更されることはなく、構成の詳細だけであったことです。 マイクロORMがより多くの開発者を獲得しているように見える今日に早送りします。なぜインラインSQLの主題全体でU-Turnを採用したように見えるのか疑問に思いました。 ORM構成ファイルがなく、より最適な方法でクエリを作成できるというアイデアが好きであることを認めなければなりませんが、SQLインジェクションなどの古い脆弱性に立ち向かうように感じており、データベースエンジンが1つなので、ソフトウェアで複数のデータベースエンジンをサポートしたい場合は、文字列のハッカーをさらに実行する必要があり、コードが判読不能で壊れやすくなります。（誰かが言及する前に、ほとんどの場合、SQLインジェクションからの保護を提供するほとんどのマイクロオームでパラメータベースの引数を使用できることを知っています） それでは、この種のことについての人々の意見は何ですか？この例ではDapperをMicro ORMとして使用し、NHibernateをこのシナリオでは通常のORMとして使用していますが、各フィールドのほとんどは非常によく似ています。 私の用語インラインSQLソースコード内のSQL文字列です。以前は、ロジックの基本的な意図を損なうソースコードのSQL文字列をめぐる設計上の議論がありました。そのため、静的に型付けされたlinqスタイルクエリが非常に人気があり、まだ1つの言語でしたが、1つのページでC＃とSql 2つの言語が生のソースコードに混ざりました。明確にするために、SQLインジェクションはsql文字列の使用に関する既知の問題の1つにすぎません。パラメーターベースのクエリでこれが発生するのを防ぐことができることは既に述べましたが、次のようなソースコードにSQLクエリを埋め込むことに関する他の問題を強調しますDBベンダーの抽象化の欠如、および文字列ベースのクエリでのコンパイル時エラーキャプチャのレベルの喪失、これらはすべて、より高いレベルのクエリ機能を備えたORMの夜明けを回避することができた問題です。 したがって、私は個々の強調された問題にはあまり焦点を当てておらず、より大局的には、ほとんどのマイクロORMがこのメカニズムを使用するため、ソースコードに直接SQL文字列を含めることがより受け入れられるようになりました。 micro ormコンテキストのないインラインSQLの詳細ですが、いくつかの異なる視点を持つ同様の質問があります。 https://stackoverflow.com/questions/5303746/is-inline-sql-hard-coding

26 database  sql  orm 

DDDによると、ドメインロジックは、シリアル化、オブジェクトリレーショナルマッピングなどの技術的な問題で汚染されるべきではありません。 それでは、ゲッターとセッターを介して公開することなく、集計の状態をどのようにシリアル化またはマッピングしますか？リポジトリの実装など、多くの例を見てきましたが、実際にはすべて、マッピングのエンティティと値オブジェクトのパブリックアクセサーに依存していました。 リフレクションを使用してパブリックアクセサーを回避することもできますが、これらのドメインオブジェクトはIMOで暗黙的にシリアル化の問題に依存します。たとえば、シリアル化/マッピングの設定を調整しないと、プライベートフィールドの名前を変更したり削除したりできませんでした。そのため、代わりにドメインロジックに焦点を当てる必要があるシリアル化を検討する必要があります。 ここで従うべき最良の妥協点は何ですか？パブリックアクセサーと一緒に住んでいますが、マッピングコード以外には使用しないでください。または、明らかな何かを見逃しただけですか？ 私は、DDDドメインオブジェクト（エンティティと値オブジェクトで構成される集約）の状態をシリアル化することに明確に興味があります。これは、一般的なシリアル化や、ステートレスサービスが単純なデータコンテナオブジェクトで動作するトランザクションスクリプトシナリオではありません。

23 object-oriented  domain-driven-design  orm  serialization 

私のほとんどのプロジェクトでHibernateを約8年間使用した後、私はその使用を思いとどまらせ、ストアドプロシージャを介してのみDBと対話するアプリケーションを求めている会社に行きました。 数週間これを行った後、私が構築し始めているアプリケーションのリッチドメインモデルを作成することができず、アプリケーションは（恐ろしい）トランザクションスクリプトのように見えます。 私が発見した問題のいくつかは次のとおりです。 ストアドプロシージャは最小量のデータを読み込むだけなので、オブジェクトグラフをナビゲートすることはできません。つまり、フィールドが異なる類似したオブジェクトがある場合があります。たとえば、顧客からすべてのデータを取得するストアドプロシージャと、顧客からアカウント情報といくつかのフィールドを取得するストアドプロシージャがあります。 多くのロジックは最終的にヘルパークラスになるため、コードはより構造化されます（エンティティは古いC構造体として使用されます）。 ストアドプロシージャから結果セットを抽出し、エンティティに配置するフレームワークがないため、より退屈な足場コード。 私の質問は： 誰もが同様の状況にあり、ストアプロシージャアプローチに同意しませんでしたか？あなたは何をした？ ストアドプロシージャを使用する実際の利点はありますか？「誰もドロップテーブルを発行できない」という愚かな点は別として。 ストアドプロシージャを使用してリッチドメインを作成する方法はありますか？オブジェクトグラフをナビゲートできるように、AOPを使用してエンティティにDAO /リポジトリを挿入する可能性があることを知っています。ブードゥー教に非常に近いので、このオプションは好きではありません。 結論 まず、答えてくれてありがとう。私が到着した結論は、ORMは（一部の人が述べたように）リッチドメインモデルの作成を有効にしないが、（多くの場合繰り返し）作業の量を単純化するということです。以下は結論のより詳細な説明ですが、ハードデータに基づいていません。 ほとんどのアプリケーションは、情報を要求して他のシステムに送信します。これを行うには、モデル用語で抽象化（ビジネスイベントなど）を作成し、ドメインモデルがイベントを送受信します。通常、イベントにはモデルからの情報の小さなサブセットが必要ですが、モデル全体ではありません。たとえば、オンラインショップでは、支払いゲートウェイはユーザーに請求するためにユーザー情報と合計を要求しますが、購入履歴、利用可能な製品、およびすべての顧客ベースは必要としません。そのため、イベントには小規模で特定のデータセットがあります。 アプリケーションのデータベースを外部システムとして使用する場合は、ドメインモデルエンティティをデータベースにマッピングできる抽象化を作成する必要があります（NimChimpskyが言及したように、データマッパーを使用）。明らかな違いは、各モデルエンティティのデータベース（レガシースキーマまたはストアドプロシージャ）へのマッピングを手作業で作成する必要があることです。2つは同期していないため、1つのドメインエンティティが部分的にマッピングされる可能性がありますデータベースエンティティ（たとえば、ユーザー名とパスワードのみを含むUserCredentialsクラスが他の列を持つUsersテーブルにマップされる）、または1つのドメインモデルエンティティが複数のデータベースエンティティにマップされる場合があります（たとえば、1対1の場合テーブルに1つのマッピングがありますが、1つのクラスにすべてのデータが必要です）。 エンティティが少数のアプリケーションでは、エンティティを横断する必要がない場合、追加の作業量は少ないかもしれませんが、エンティティを横断する条件付きの必要がある場合は増加します（したがって、ある種の「怠lazな」読み込み」）。アプリケーションが成長してより多くのエンティティを持つようになると、この作業は増加するだけです（そして、非線形に増加すると感じています）。ここでの私の仮定は、ORMを再発明しようとしないことです。 DBを外部システムとして扱うことの利点の1つは、アプリケーションの2つの異なるバージョンを実行し、各アプリケーションのマッピングが異なる状況を回避できることです。これは、本番環境への継続的な配信のシナリオでより興味深いものになります...しかし、これは、ORMでもそれほどではないかもしれません。 開発者は、データベースにアクセスできなくても、悪意のあるコードを挿入するだけで、システムに格納されている情報のほとんどではなくてもほとんどを取得できることに基づいて、セキュリティの側面を無視します。親愛なる主よ、顧客のクレジットカードの詳細を記録する行を削除するのを忘れたとは信じられません！）。 小さな更新（6/6/2012） ストアドプロシージャ（少なくともOracleの場合）では、テーブルの構造を変更するとプロシージャとトリガーが無効になるため、ダウンタイムがゼロの連続配信のようなことはできません。したがって、DBが更新されている間、アプリケーションもダウンします。Oracleは、このためのEdition-Based Redefinitionと呼ばれるソリューションを提供しますが、この機能について私が尋ねた少数のDBAは、実装が不十分であり、運用DBに配置しないと述べました。

21 java  design  orm  stored-procedures  domain-driven-design 

私は現在のシステム以来、本格的なORMよりも職場での実装が簡単である可能性があるため、Dapperや（.NET 4.0に依存しているためそれほどではありませんが）いわゆるいわゆる「マイクロORM」を検討しています。ストアドプロシージャに大きく依存しているため、NHibernateやEFなどのORMを使用するには、大幅なリファクタリングが必要になります。フル機能のORMよりもこれらの1つを使用する利点は何ですか？データベース接続を取り巻く薄いレイヤーのように見えますが、それでも未加工のSQLを記述する必要があります-多分間違っているでしょうが、そもそもORMの理由は、SQLを記述する必要がないということです。自動的に生成できます。特に、複数テーブルの結合およびテーブル間のマッピング関係は、純粋なSQLでは困難ですがORMでは簡単です。 たとえば、Dapperの例を見てみましょう。 var connection = new SqlConnection(); // setup here... var person = connection.Query<Person>("select * from people where PersonId = @personId", new { PersonId = 42 }); コマンドを記述したり、パラメータを設定したり、Builderを使用してエンティティをマップし直したりする必要がないことを除いて、ハンドロールADO.NETデータレイヤーの使用とはどのように違いますか。ストアドプロシージャコールをSQL文字列として使用することもできるようです。 Micro ORMを使用する意味がある場合、ここで見逃している他の具体的な利点はありますか？おそらく数行のコードを除いて、ADO.NETを使用する「古い」方法で何かを保存する方法を実際には見ていません-実行する必要があるSQLを把握するために書く必要があります。テーブル（IMHO ORMが最も役立つ部分）間の関係をマッピングする必要があります。

21 .net  orm 

最近、リポジトリパターンをORMと組み合わせて使用​​するのは良い習慣ではないことを読みました。私の理解から、これはSQLデータベース上で提供する抽象化がパターンに含まれるには漏れやすいためです。 これについていくつか質問があります。 ORMを切り替えたい場合はどうしますか？リポジトリに含まれていない場合、アプリケーションにORM固有のコードが含まれます。 ORMを使用せず、データアクセスとオブジェクトデータの入力にADO.NETを使用している場合、リポジトリパターンはまだ有効ですか？ リポジトリパターンではなくORMを使用する場合、よく使用されるクエリはどこに保存しますか？各クエリをクラスとして表現し、インスタンスを作成するための何らかのクエリファクトリを用意するのが賢明でしょうか？

20 design-patterns  orm  repository