31

教義に関するあなたの経験は何ですか? 私は ORM のような人ではありませんでした。ほとんどの場合、adodb のような基本的な db 抽象化レイヤーだけで管理していました。

しかし、私はそれのすべての概念と利点を理解していました. そのため、ORM を必要とするプロジェクトが登場したとき、ORM フレームワークの 1 つを試してみようと思いました。

doctrine と propel のどちらかを決定する必要があるため、phing 要件を処理したくなかったので doctrine を選択しました。

何を間違えたのかわからない。私は正しい考え方で入ってきました。そして、私は決して「ジュニア」phpキディではありません。しかし、私はあらゆる段階でシステムと戦ってきました。多くのドキュメントがありますが、すべてが少し混乱しているように感じます。そして、YAML から db テーブルへの作成などの単純なものは機能せず、エラーも何も発生せずに失敗します。他の多くの機能は少しファンキーに機能しますが、機能する前に少しだけ微調整する必要があります。

多分私はここで愚かな初心者の仮定をいくつか作りました. でも今はそのシステムが大嫌いです。

誰かが提供できるヒントや、この件に関する優れたリソースや、これに関する権威あるサイト/人物を教えてくれるヒントはありますか? それとも、「うまく機能する」別の ORM フレームワークを推奨するだけでしょうか?

4

12 に答える 12

47

気持ちがまちまちです。私はSQLのマスターですが、それは検証が非常に簡単だからです。正しい結果が得られるまで、SELECTステートメントをすばやくテストできます。そして、リファクタリングは簡単です。

Doctorineやその他のORMには、抽象化レイヤーが非常に多く、OCD（強迫性/強迫性）のように見えます。Doctrineを試した最新のプロジェクトでは、いくつかの壁にぶつかりました。ほんの数分でSQLで記述できるとわかっていたものの解決策を見つけるのに数日かかりました。それはすっごくイライラします。

私は不機嫌です。SQLのコミュニティは巨大です。Doctrineのコミュニティ/サポートはごくわずかです。確かにあなたは情報源を見てそれを理解しようとすることができます...そしてそれらは理解するのに数日かかる問題です。

結論：自分でグロッキングするために多くの時間を計画せずに、DoctrineやORMを試してはいけません。

于 2010-02-18T19:55:19.913 に答える
9

Propel を Symfony で 2 年間使用し、Doctrine を Symfony で 1 年以上使用しています。MVC フレームワークを使用した ORM への移行は、私たちが行った最良のステップであると言えます。Doctrine の使い方を学ぶには時間がかかりますが、Doctrine を使い続けることをお勧めします。最終的には、コードがより読みやすく柔軟になることがわかります。

開始する場所を探している場合は、Symfony Jobeet チュートリアルhttp://www.symfony-project.org/jobeet/1_4/Doctrine/en/ (第 3 章、第 6 章で基本が説明されています)をお勧めします。ドクトリンのドキュメント。

上で書いたように、Doctrine をしばらく使用しています。私たちの仕事をより快適にするために、ORM Designer (www.orm-designer.com) というツールを開発しました。このツールでは、グラフィカル ユーザー インターフェイスで DB モデルを定義できます (YAML ファイルはもう必要ありません :-)。 ）。役立つチュートリアルもいくつかあります。

于 2010-01-11T22:30:15.880 に答える
6

私の経験はあなたの経験と似ています。doctrine を使い始めたばかりで、Propel を使ったことはありません。しかし、Doctrine には非常に失望しています。そのドキュメントはひどいです。整理が不十分で、かなり不完全です。

于 2010-01-19T20:24:51.060 に答える
6

Propel と Doctrine は PDO を使用します。PDO には、Oracle データベースに関する多くの未解決のバグがあります。それらはすべて CLOB フィールドに関連しています。Oracle を使用している場合は、新しいプロジェクトを開始する前に、この点に留意してください。バグは何年も前から開いています。Doctrine と PDO は、Oracle と CLOB を使用するとクラッシュします

于 2010-02-24T09:43:05.803 に答える
5

私は所有していない既存のデータベースから作業しなければならなかった中規模のプロジェクトで Doctrine を使用しています。多くの組み込み機能を提供しますが、大きな不満が 1 つあります。

データベースからモデルを生成する必要があり、その逆ではないため、モデルはデータベースに近すぎます。フィールドにはデータベースの列と非常によく似た名前が付けられており、オブジェクトを取得するには、必須の SQL でクエリを実行する必要があります (ここでそのコードを入れて、どのようにテストしますか?)など。

最後に、古い dao/model アプローチを使用して教義を除外する方が簡単ではないかどうか疑問に思う、教義の複雑なラッパーを作成する必要がありました。陪審員はまだそれについて出ていません。幸運を！

于 2009-07-29T11:50:30.870 に答える
5

パーティーには少し遅れましたが、ここで 2 セント投げさせてください。私が使用しているフレームワークであるLaravelと接続します。

アクティブ レコード vs. データ マッピング vs. 適切な OOP

Laravel や他の多くのフレームワークはActive Recordを愛用しています。単純なアプリケーションには最適で、些細な DB 管理の時間を節約できます。ただし、OOP の観点からは、これは純粋なアンチ パターンです。SoC (関心の分離) が殺されました。モデル属性と SQL 列名の間の結合を作成します。拡張機能と将来の更新にはひどい。

プロジェクトが成長するにつれて (そして、そうなるでしょう!)、ActiveRecord はますます苦痛になります。SQL構造を簡単に更新することさえ考えないでください。PHP コード全体に列名があることを思い出してください。

私は、将来的にかなり大きくなることを目指すプロジェクトに雇われました。ActiveRecordの限界を見た。私は 3 週間座って、DB を上のレイヤーから分離する Data Mapper を使用してすべてを書き直しました。

ここで、 Data Mapperに戻り、なぜ Doctrine を選択しなかったのかを説明します。

Data Mapperの主なアイデアは、データベースをコードから分離することです。これは、OOP の観点からは正しいアプローチです。SoCのルール！私はDoctrineを詳細にレビューしましたが、すぐに気に入らない点がいくつかありました。

  • マッピング。コメントをコマンドとして使用する人がいるでしょうか? これは非常に悪い習慣だと思います。PHP クラスを使用してマッピング関係を保存しないのはなぜですか?
  • マップの Yaml または XML。繰り返しますが、なぜですか?? 通常の PHP クラスを使用できるのに、テキスト ファイルの解析に時間を浪費する必要はありません。さらに、クラスを拡張したり、継承したり、データだけでなくメソッドを含めることもできます。等。
  • マッパーとデータを運ぶモデルがある場合、それはモデルを格納するマッパーでなければなりません。などの方法$product->save()はよくありません。モデルはデータを処理します。DB への保存は気にする必要はありません。非常に密なカップリングです。マッパーの構築に時間を費やすのであれば、$mapper->save($product). 定義上、データの保存方法を知っているのはマッパーです。

Doctrine や Eloquent などのツールを使用すると、最初は時間を節約できます。しかし、ここで個人的に難しい質問があります。/開発時間/将来の更新/価格/シンプルさ/OOP 原則の遵守/の間の適切な妥協点は何ですか? 最終的には、適切に答えて判断するのはあなた次第です。

Doctrine の代わりに自分の DataMapper

私は独自の DataMapper を開発することになり、いくつかの小さなプロジェクトで既に使用しています。非常にうまく機能し、拡張と再利用が簡単です。ほとんどの場合、パラメータを設定するだけで、新しいコードは必要ありません。

主な原則は次のとおりです。

  • モデルは、Laravel のモデルと同様にデータを運びます。次の例の変数$modelの例。
  • ModelMapには、モデルの属性を SQL データベースのテーブルの列にマップするフィールドが含まれています。ModelMaps は、テーブル名、ID などを認識しています。どの属性を json に変換する必要があるか、どの属性を非表示にする必要があるか (deleted_at など) を認識しています。この ModelMap には、同じ名前の列 (接続されたテーブル) のエイリアスが含まれています。変数の例: $modelMap.
  • ModelDataMapperは、コントローラーでModelおよびModelMapを受け取り、store/getById/deleteById 機能を提供するクラスです。あなたは単に電話$modelMapper->store($model)をかけるだけです。
  • ベース DataMapper は、ページネーション、検索機能、配列の json への変換、タイムスタンプの追加、ソフト削除のチェックなども処理します。単純な使用法では、ベース DataMapper で十分です。より複雑なものについては、継承を使用して簡単に拡張できます。
于 2018-08-16T13:27:03.140 に答える
4

2016 年に Doctrine ORM を使用し、約 2 ～ 2.5 年の経験があります。

固有の矛盾

SELECT i, p            
FROM \Entity\Item i
JOIN i.product p
WHERE ...

エンティティがItemと であると仮定しProductます。それらは に接続されてItem.product_idおりProduct.id、とともに表示したいものをProduct含んでいます。Product.modelItem

上記の SQL を使用して、データベースから同じ "product.model" を取得しますが、SQL パラメータは異なります。

//SELECT i, p
$ret[0]->getProduct()->getModel();          

//SELECT i as item, p as product
$ret[0]['item']->getProduct()->getModel();  

//SELECT i as item, p.model as model
$ret[0]['model'];

私が作っているポイントはこれです：

出力 ResultSet 構造は、DQL/ORM SELECT ステートメントの記述方法によって大幅に変わる可能性があります。

オブジェクトの配列からオブジェクトの連想配列の配列、連想配列の配列まで、目的に応じてSELECT. SQL に変更を加える必要があると想像してください。次に、コードに戻って、結果セットからのデータの読み取りに関連するすべてのコードをやり直す必要があると想像してください。痛い！痛い！痛い！ 数行のコードであっても、結果セットの構造に依存します。完全な分離/共通標準はありません。

Doctrine の得意なこと

いくつかの点で、SQL の処理、独自のテーブルの作成と維持が不要になります。完璧ではありません。時々失敗し、MySQL コマンドラインに移動して SQL を入力し、Doctrine とあなたが満足するポイント、Doctrine がカラムタイプを有効と見なすポイント、カラムタイプに満足できるポイントに調整する必要があります。独自の外部キーやインデックスを定義する必要はありません。自動で魔法のように行われます。

ドクトリンが苦手なこと

非常に高度な SQL を DQL/ORM に変換する必要があるときはいつでも苦労するかもしれません。それとは別に、上記のような矛盾に対処することもできます。

最終的な考え

テーブルを作成/変更し、テーブルデータをオブジェクトに変換して永続化し、準備済みステートメントやその他のチェックアンドバランスを使用してデータをより安全にするDoctrineが大好きです.

PHP のオブジェクト指向インターフェース内から Doctrine によって永続ストレージが管理されているという感覚が気に入っています。自分のデータを自分のコードの一部と考えることができ、ORM がデータベースとのやり取りの厄介なことを処理してくれるという、うずくような感覚を覚えます。データベースはローカル変数のように感じられます。データを大事にすれば、データベースはあなたを愛してくれるということを理解しています。

私は Doctrine が嫌いです。一貫性がなく、学習曲線が難しく、SQL で何かを書く方法を知っているときに DQL の独自の構文を調べなければならないからです。SQL の知識はすぐに利用できます。DQL には、専門家がそれほど多くなく、(SQL と比較して) 行き詰まったときに役立つ蓄積された知識もありません。

于 2016-06-06T15:52:09.353 に答える
3

私はDoctrineの専門家ではありません.Doctrineを使い始めたばかりで、少し複雑な経験であることを認めなければなりません. それはあなたのために多くのことをしますが、これまたはあれを行うように指示する方法がすぐにわかるとは限りません。

たとえば、自動関係検出で YAML ファイルを使用しようとすると、多対多の関係が php モデル定義に正しく変換されませんでした。あなたが言及したようにエラーはありません。多対多としてまったく扱わなかったからです。

あれやこれやのやり方や、要素がどのように相互作用するのかを理解するには、おそらく時間が必要だと思います。そして、一度に一歩ずつ物事を行う時間を持つことは良いことであり、一種の孤立した状態で一度に1つずつ問題に対処します. 一度に多くのことをしようとすると圧倒される可能性があり、何かがうまくいかない場所を実際に見つけるのが難しくなる可能性があります.

于 2009-05-08T22:02:33.347 に答える
3

PHP 用のさまざまな ORM ライブラリを調査した後、PHP ActiveRecord ( を参照) に決定しました。私の決定は、構成がほとんどまたはまったくないこと、ライブラリの軽量な性質、およびコード生成の欠如に帰着しました。Doctrine は、私が必要としているものに対して単純に強力すぎます。PHP ActiveRecord ができないことは、ラッパー層に実装できます。少し時間を取って、ORM の要件を調べて、PHP ActiveRecord のような単純なものが必要なものを提供するか、自作のアクティブ レコード実装の方が優れているかを確認することをお勧めします。

于 2010-07-18T03:05:38.630 に答える