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

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 9年前に閉鎖されました。 選択したフレームワークで推奨されているORMを使用し始めています。ORMが提供する抽象化の追加レイヤーのアイデアは気に入っていますが、これが本当に何を意味するのか理解し始めています。これは、データベース（mysql）を使用しなくなったため、mysql固有の機能が存在しなくなったためにウィンドウの外に出てしまったことを意味します。 ORMの考えは、データベースをすべて非依存にすることで、私を助けようとしているということです。これはすばらしいように聞こえますが、多くの場合、特定のデータベースシステムを選択する理由があります。しかし、データベースにとらわれないルートをたどることにより、ORMは最小公約数を取ります。つまり、最小の機能セット（すべてのデータベースでサポートされる機能）になります。 長期にわたって基礎となるデータベースを切り替えないことを知っている場合はどうなりますか？データベース固有の機能にもアクセスしてみませんか？

19 database-development  orm 

私は私が移動する方が良いだろう（もしあれば）どのような状況では、コードとEntity Frameworkののメイク使用されているすべての私のビジネス・ロジックを、持っている場合は、いくつかのストアドプロシージャにビジネスロジックを、代わりのコードでそれをすべて保ちますか？ 明確にするために、代わりにではなく、現在のセットアップ（コード内のビジネスロジック）と組み合わせて意味します。ストアドプロシージャですべてのビジネスロジックを使用することの長所と短所を求めている同様の質問を多数見ましたが、ビジネスロジックの残りを保持しながら、エッジケースロジックでストアドプロシージャを控えめに使用することについてはあまり知りませんでしたコードで。 違いがある場合は、MSSQLとEntity Frameworkを使用しています。 これらは、以前にストアドプロシージャを使用したことがある状況です。 実行に数分かかっていた複雑なレポート（これはWebアプリのページでした）。LINQが提供するものよりもはるかに効率的な（実行に数秒しかかからない）SQLを作成できることがわかりました。 Webアプリケーションは、アプリケーションに関係のない他の多くの機密情報を含む別のデータベースのいくつかのテーブルを読み書きする必要がありました。すべてにアクセスするのではなく、必要なことだけを行い、限られた情報のみを返すストアドプロシージャを使用しました。Webアプリケーションは、テーブルなどにアクセスせずに、このストアドプロシージャのみにアクセスできます。 この質問をする前に私が見た他の投稿： ストアドプロシージャは、世界最大のITソフトウェアコンサルティング会社の1つで悪い習慣ですか？ Webアプリケーションのストアドプロシージャにすべてのビジネスロジックを保持することの長所と短所 /programming/15142/what-are-the-pros-and-cons-to-keeping-sql-in-stored-procs-versus-code /dba/2450/what-are-the-arguments-against-or-for-putting-application-logic-in-the-database/2452#2452 ORMを使用せず、ストアドプロシージャを使用する場合

19 design  sql-server  orm  business-logic  stored-procedures 

今日、私は組織の別の開発者とデータベースマップクラスにメソッドを追加する場所と方法について、激しい議論になりました。を使用しsqlalchemy、データベースモデルの既存のコードベースの大部分は、クラス名を持つマッピングされたプロパティのバッグ、データベーステーブルからpythonオブジェクトへのほぼ機械的な変換に過ぎません。 議論の中で、私の立場は、ORMを使用する主な価値は、マップされたクラスに低レベルの動作とアルゴリズムを付加できることだということでした。モデルは最初にクラスであり、2番目に永続的です（ファイルシステムでxmlを使用して永続的である可能性があるため、気にする必要はありません）。彼の見解では、すべての動作は「ビジネスロジック」であり、必然的に、データベースの永続化のみに使用される永続モデル以外のどこかに属します。 私は確かにビジネスロジックとは区別されていると思いますが、それは実装方法の下位レベルからある程度分離されているので、分離する必要があります前の段落で議論しましたが、私はそれが何であるかについて指を置くのに苦労しています。私は、彼らがしたいとのAPI呼び出しているユーザーには、（我々の場合には、HTTP「安らか」である、）APIが何であるかのより良い感覚を持っていません、彼らが行うことを許可されているものとは異なった、そしてどのように完了します。 tl; dr：ORMを使用する場合、マップされたクラスのメソッドにはどのような種類の要素を含めることができますか？

16 orm  abstraction  business-logic 

一般的な状況は次のとおりです。 ORMフレームワークを使用するアプリケーションに一括操作を実装する必要があります。 最初のパスの後、重大なパフォーマンスの問題に気づきました。 ここに私の質問があります： この状況では、生のSQLを含むソリューションを好むべきでしょうか？ または、ORMフレームワークを使用した一括操作に一般的に関連する問題を軽減するのに役立つ、よく知られた設計パターンはありますか？ 編集： アプリケーション全体からORMフレームワークを削除する必要があるかどうかは尋ねません。 私は尋ねています：アプリケーションのこの小さなスライスのためにORMフレームワークを放棄する必要がありますか？

15 orm  heuristics 

DoctrineとPropelは両方とも単一および具体的なテーブル継承を利用してオブジェクトの関係をマップします。前者は単一のテーブルにマッピングされたクラスツリー内のすべての可能なフィールドを参照しますが、後者は各クラスを特定のテーブルにマッピングし、継承階層の共通フィールドを複製します。 これによりORM装置が容易になりますが、データベース設計が悪いことを示唆しています。これらの悪い設計パターンは、データベースに適用されますか？

14 database-development  database  orm 

データモデル/データベースのプレゼンテーションレイヤーとエンティティフレームワークにJSONを使用したMVCを活用するWebサイトの作成を実験しています。私の問題は、ModelオブジェクトをJSONにシリアル化することに関係しています。 私は自分のデータベースを作成するためにコードファーストの方法を使用しています。コードファーストの方法を実行するとき、1対多の関係（親/子）では、子が親への参照を持つ必要があります。（サンプルコードはタイプミスかもしれませんが、写真を取得します） class parent { public List<child> Children{get;set;} public int Id{get;set;} } class child { public int ParentId{get;set;} [ForeignKey("ParentId")] public parent MyParent{get;set;} public string name{get;set;} } JsonResultを介して「親」オブジェクトを返す場合、「子」にはクラス親のプロパティがあるため、循環参照エラーがスローされます。 ScriptIgnore属性を試しましたが、子オブジェクトを見ることができません。ある時点で、親子ビューに情報を表示する必要があります。 循環参照を持たない親と子の両方の基本クラスを作成しようとしました。残念ながら、baseParentとbaseChildを送信しようとすると、これらは派生クラスとしてJSONパーサーによって読み取られます（この概念が私を逃れていると確信しています）。 Base.baseParent basep = (Base.baseParent)parent; return Json(basep, JsonRequestBehavior.AllowGet); 私が思いついた1つの解決策は、「ビュー」モデルを作成することです。親クラスへの参照を含まないシンプルなバージョンのデータベースモデルを作成します。これらのビューモデルにはそれぞれ、データベースバージョンを返すメソッドと、データベースモデルをパラメーターとして取得するコンストラクターがあります（viewmodel.name = databasemodel.name）。この方法は機能しますが、強制されているようです。 注：ここで投稿しているのは、これがより議論に値すると思うからです。別のデザインパターンを活用してこの問題を克服することも、モデルで別の属性を使用するのと同じくらい簡単にすることもできます。私の検索では、この問題を克服する良い方法を見ていません。 私の最終目標は、サーバーと通信してデータを表示するためにJSONを大幅に活用する素晴らしいMVCアプリケーションを持つことです。レイヤー全体で一貫したモデルを維持しながら（または、私が思いつく限り）。

13 asp.net-mvc  entity-framework  orm  json 

（ActiveRecord）モデルに加えて、常にデータベースレベルで制約を適用しています。しかし、私はこれが本当に必要かどうか疑問に思っていましたか？ 少しの背景 私は最近、モデルの基本的な自動タイムスタンプ生成方法を単体テストする必要がありました。通常、テストはモデルのインスタンスを作成し、検証なしで保存します。ただし、テーブル定義でnullにできない他の必須フィールドがあります。つまり、ActiveRecord検証をスキップしてもインスタンスを保存できません。だから私はdb自体からそのような制約を削除し、ORMにそれらを処理させる必要があるかどうかを考えていますか？ db、imoの制約をスキップした場合に考えられる利点 - データベースを移行することなく、モデル内の検証ルールを変更できます。 テストで検証をスキップできます。 考えられる不利益は？ ただし、ORM検証が失敗またはバイパスされる可能性がある場合、データベースは制約をチェックしません。 どう思いますか？ 編集このケースでは、データベースからモデルを生成するYii Frameworkを使用しているため、データベースルールも生成されます（ただし、生成後はいつでも記述できます）。

13 database  orm  validation  dry 

PetaPoco micro-ORMを使用しています。ORMツールを使用してデータベースを操作するのは確かに非常に簡単で安全ですが、私が嫌いなのは余分なコードだけです。以前はほとんどのコードをデータベース自体に配置し、ストアドプロシージャ、トリガーなど、RDBMSのすべての機能を使用していました。 ストアドプロシージャ/トリガーでORMを使用しない場合、またはその逆の場合を知りたいです。

13 orm  rdbms  stored-procedures 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 Javaでの永続性 過去数年にわたって、EJB 2.0、Hibernate、JPA、および自家製の概念などを使用して、Javaの永続性抽象化の分野での経験を集めてきました。彼らは、急な学習曲線と多くの複雑さを持っているように思えました。さらに、SQLの大ファンとして、多くの抽象化モデルがSQLを抽象化しすぎて、SQLではなく非常に優れた概念である「基準」、「述語」、「制限」などの概念を作成すると考えました。 Javaでの永続性抽象化の一般的な考え方は、RDBMSがオブジェクト指向の世界と何らかの形で一致するオブジェクトリレーショナルモデルに基づいているようです。ORM討論は常に感情的なものでした。すべての人に適した単一の解決策は存在しないようです。そのような解決策が存在する可能性があるとしてもです。 jOOQ ORM関連の問題を回避する方法の個人的な好みは、リレーショナルの世界に固執することです。データモデルのパラダイムの選択は、個人的な好みであるため、または具体的な問題に最適なデータモデルの問題であるため、議論のトピックではありません。私が始めたいと思う議論は、jOOQと呼ばれる私自身の永続化ツールに関するものです。私はjOOQを設計して、最新の永続化ツールが持つ利点のほとんどを提供します。 SQLに基づくドメイン固有言語 基礎となるデータベーススキーマをJavaにマッピングするソースコード生成 多くのRDBMSのサポート いくつかの最新の永続化ツールにあるいくつかの機能を追加します（間違っている場合は修正してください）： 複雑なSQLのサポート-ユニオン、ネストされた選択、自己結合、エイリアス、ケース節、算術式 非標準SQLのサポート-ストアドプロシージャ、UDT、ENUMS、ネイティブ関数、分析関数 詳細については、ドキュメントページhttp://www.jooq.org/learn.phpをご覧ください。LinqはSQL専用に設計されているわけではありませんが、Linq for C＃に非常によく似たアプローチが実装されていることがわかります。 質問 さて、私はSQLの大ファンだと言って、他の開発者がjOOQ（またはLinq）に対する私の熱意を共有するかどうか疑問に思います。永続性抽象化へのこの種のアプローチは実行可能なものですか？あなたが見るかもしれない利点/欠点は何ですか？どうすればjOOQを改善できますか？また、あなたの意見には何が欠けていますか？概念的または実際的にどこで間違ったのですか？ 批判的だが建設的な答えを高く評価 議論は感情的なものであることを理解しています。すでに同様のことを行う多くの素晴らしいツールがあります。私が興味を持っているのは重要ですが、あなた自身の経験や読んだ記事に基づいた建設的なフィードバックです。

12 java  orm  database  linq 

私は最近、エンティティフレームワークのような強力なORMでリポジトリパターンを使用することに対して多くの議論を読みました。リポジトリパターンは作業単位機能とともにリポジトリに似た機能を組み込んでいるからです。 単体テストのような状況でパターンを使用することに対するもう1つの論点は、より汎用的な実装がIQueryableを活用するため、リポジトリパターンは漏れやすい抽象化であるということです。 リポジトリパターンの使用に反対する議論は私には理にかなっていますが、提案された抽象化の代替方法はしばしば混乱を招き、問題と同じくらいやり過ぎです。 Jimmy Bogardsのソリューションは、抽象概念を吹き飛ばすことと、彼自身のアーキテクチャを導入することの組み合わせのようです。 https://lostechies.com/jimmybogard/2012/10/08/favor-query-objects-over-repositories/ リポジトリが不必要になっている別の例....しかし、私のアーキテクチャを使用してください！ http://blog.gauffin.org/2012/10/22/griffin-decoupled-the-queries/ 別の... http://www.thereformedprogrammer.net/is-the-repository-pattern-useful-with-entity-framework 私は、それ自体が設計されていない「過度に複雑な」リポジトリパターンアプローチの明確な代替物や代替物を見つけていません。

12 domain-driven-design  entity-framework  orm  nhibernate  repository-pattern 

リポジトリにORMを使用している場合、データベースからすでに十分に抽象化されていると思います。 ただし、私が現在働いているところでは、後でORMを変更したい場合に備えて、ORMを抽象化するレイヤーが必要だと誰かが信じています。 多くのORMで機能するレイヤーを作成するのは本当に必要なのでしょうか、それとも単純に頭がかかりますか？ 編集 より詳細に説明するために： AutoMapperでマップされるPOCOクラスとEntityクラスがあります。エンティティクラスは、リポジトリレイヤーによって使用されます。リポジトリレイヤーは、追加の抽象化レイヤーを使用して、Entity Frameworkと通信します。 ビジネスレイヤーは、Entity Frameworkに直接アクセスできません。ORM上の抽象化の追加レイヤーがなくても、これはリポジトリレイヤーを使用するサービスレイヤーを使用する必要があります。どちらの場合も、ビジネスレイヤーはORMから完全に分離されています。 主な議論は、将来ORMを変更できるようにすることです。リポジトリレイヤー内に実際にローカライズされているため、私にとっては既に十分に分離されており、「品質」コードを得るために抽象化の追加レイヤーが必要な理由はわかりません。

12 database  orm 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 2年前に閉店。 C ++やJavaなどのオブジェクト指向プログラミング言語の一般的なチュートリアルを検討してください。アカウント、注文、アイテムなど（またはほぼ同等のもの）を表すオブジェクトを使用して、簡単な注文処理システムを作成します。完全に直感的に理解できますが、ダイニングテーブルにいる象は、これらがインメモリオブジェクトであるため、現実的ではないということです。実際のシステムでは、アカウント、注文などはそもそもメモリに実際に存在するのではなく、データベースに存在し、メモリ表現はその短命のミラーにすぎません。 データベースを読み書きするために多くのコードを自分で書くこともできますが、それは退屈でエラーが発生しやすいため、実際に誰もそれを行いません。 誰もがORMを使用することになりますが、それらはそれ自体非常に問題が多いため、有名な論文では「ORMのベトナム」と呼ばれています。 プログラミング言語とデータベースがお互いを知らない別個のものであるのと同じくらい、オブジェクトとリレーショナルの不一致ではないと思います。推測：解決策は、プログラミング言語とデータベースクエリ言語の両方である単一の言語を使用することです。そのためには、言語ランタイムもデータベースであり、JITコンパイラもクエリオプティマイザーである必要があります。 それが私が見た問題の要約です。私の質問は、まだ誰かがいますか、 実際にこのような統合システムを構築しました 試みたが、そのような統合システムの構築に失敗した あなたがそのような建築をどのように進めるのか、またはなぜ、なぜそうでないのかというトピックに関する実質的なものを書かれている 問題を解決する別の方法を思い付きますか？

11 database  language-design  orm 

私は過去にMDA（モデル駆動型アーキテクチャ）ツールを使用しましたが、UMLを介してモデル化し、これにより、とりわけビジネスエンティティ（ドメインモデル）とORM（マッピングなど）が生成されました。 ドメインで動作するビジネスコードとサービスの多くはモデルの一部であり、リポジトリはビジネスエンティティを返していました（そのため、別のORMに切り替えることはできませんでした（望んでいなかった））。 しかし、今はプロジェクトを始めており、DDDについて考えたいと思います。 これまでのところ、ビジネスロジックをドメインモデルに入れ、リポジトリを介してORM（どちらを選択した場合でも）で作業するように感じています。ただし、アプリケーションのORM部分に引き続きMDAツールを使用したい場合、ここで作成されたモデルは非常に貧弱です（つまり、ビジネスロジックが含まれていません）。同様に、ORMにエンティティフレームワーク（.net）またはNHibernateを使用した場合、それも貧血モデルになります。NHibernateをそのまま使用した場合、ビジネスロジックをどこに置くかわかりません。 私はこのように考えるのは正しいですか、つまりDDDではドメイン内のすべてのビジネスロジックを使用し、リポジトリ経由で永続化するためにORMを使用するだけですか？

10 orm  entity-framework  domain-model  nhibernate  domain-driven-design 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 5年前休業。 私が引き受ける予定の新しいプロジェクトのEntity Frameworkを調べています。その研究の一環として、業界の専門家に、安定していて「現実世界」での実装の準備ができているかどうか尋ねています。 実行中は： EF NHibernate DevExpress XPO 私はすでにXPOの経験が豊富ですが、特に満足していません。

10 .net  orm  entity-framework 

最初に、SQLを使用してデータベース作業の95％を完了したと言います。最近、NHibernateやDoctrineなどのさまざまなORMの調査を行いました。 多くのSQLと、ORMが提供するデータベースの移植性を知る必要がないことの利点がわかります。しかし、SQLを理解することでORMとの連携がより効果的になることもわかります。私のキャリアの中で、アプリケーションの最大の変更はデータベースベンダーになるとしか思えません。 私はSQLの作成に非常に慣れており、ORMを使用することでよく教えられる利点を実現していないようなので、ORMのヘビーユーザーへの私の質問は次のとおりです。 どのようなWeb開発プロジェクトがORMの使用から最も恩恵を受けますか？

10 php  asp.net  sql  ruby-on-rails  orm