1

私はサイトのフォーラムのようなコンポーネントを書いています。その使用例は、トピック、投稿、グループなどが作成される reddit や quora のようなものとかなり似ています。私は python と sqlalchemy コアを使用していますが、ORM を使用する必要があるかどうかについてまだ議論しています。私がそれを使用したくない本当の理由は、生成されたクエリが問題を引き起こす可能性があり、物事が成長するにつれて、最適化のためにとにかく生のSQLを処理する必要があると言われたので、物事が進むにつれて対処する別のコンポーネントを避けることです.

ORM を使用して退屈な CRUD とデータ マーシャリングをすべて処理していない人に、私はただ興味があります。すべてを書き出しますか、それとも別のアプローチをとりますか? 退屈なデータのマーシャリングをどのように処理しますか? 結果オブジェクトを取得して、単に次のようなことを行うより良い方法はありませんか?

result = user_dao.get_user(userid)
user.name = result.name
user.email = result.email
user.passwd = result.password_hash
[...]

特定のオブジェクト/エンティティでは、15 個以上の属性がある場合、これはかなり面倒になることがあります。

4

4 に答える 4

3

selection/update/etc ステートメントを実行するだけでなく、ORM を使用する理由はたくさんあります。たとえば、カスタム機能をアプリケーションのレコードに結び付けたり、SQL インジェクションを防止したり、モデルの背後にある新しいクラス タイプに効果的に移動したり、その他さまざまなことを行うことができます。

はい、アプリケーション用にカスタム SQL を作成する必要がある場合もありますが、ORM の結合機能では、これはそれほど一般的ではありません。DBIx for Perl が「仮想」型を提供していることを私は知っています。この型では、カスタムの select ステートメントをクラスに入れても、そのオブジェクトに結び付けられたメソッドを書くことができます。

選択した項目にメソッドを結び付ける機能により、コードの DRY 性が向上します。これを SQL インジェクションの防止と組み合わせると、ORM を使用するようにして、本当に正当な理由がある場合にのみ使用しないことをお勧めします。CRUD とデータ マーシャリングを処理するために使用するものはすべて、最終的には新しい「ORM」になるだけなので、他の人に面倒な作業を任せてみませんか?

于 2013-04-12T01:14:24.587 に答える
2

この質問は、すべての反対票に値するものではないようです。著者はここに正当な懸念を持っていると思います。

私は個人的に ORM ハイブリッドを選びました。SQL Alchemy のようなものは、私が達成したいことに対して少し重すぎる傾向があり、常に最も効率的なクエリを生成するとは限りません。あなたが躊躇する理由はよくわかります。

これは、複数のテーブルからフィールドを取得する場合に特に当てはまります。SQL Alchemy を初めて使用したとき、複数の SELECT ステートメントを結合するかどうかは難しい決断であることがわかりました。それ以来、私は従来の ORM を避けてきました。

Stephen Schmidt は、一般的に ORM に対してまともな主張をしていますが、私は満足できる妥協点があると思います。

PyORMishを見てみましょう。それは本当に新しいですが、かなりよくテストされています。これは実際には ORM ではありませんが (したがって "ish" です)、ボイラー プレート コードを減らし、必要に応じて生の SQL に簡単にアクセスできるようにします。

免責事項: 私は PyORMish の作成者です

于 2013-04-14T20:34:20.643 に答える