sql - エンティティオブジェクトが必要な理由

Question

現在受け入れられているエンタープライズアプリケーションの設計パラダイムのメリットについて、率直で思慮深い議論が必要です。

エンティティオブジェクトが存在する必要があるとは確信していません。

エンティティオブジェクトとは、"Person"、"Account"、"Order" など、アプリケーション用に構築する傾向がある典型的なものを意味します。

私の現在のデザイン哲学は次のとおりです。

すべてのデータベースアクセスは、ストアドプロシージャを介して行う必要があります。
データが必要なときはいつでもストアドプロシージャを呼び出し、SqlDataReader または DataTable の行を反復処理します。

(注: 私は Java EE を使用してエンタープライズアプリケーションも構築しました。Java 関係者は、私の .NET の例を同等のものに置き換えてください)

私はアンチOOではありません。エンティティだけでなく、さまざまな目的のために多くのクラスを作成します。私が作成するクラスの大部分が静的ヘルパークラスであることは認めます。

私はおもちゃを作っているわけではありません。私が話しているのは、複数のマシンに展開された大規模で大量のトランザクションアプリケーションです。Web アプリケーション、Windows サービス、Web サービス、B2B インタラクションなど。

OR マッパーを使用しました。いくつか書きました。私は Java EE スタック、CSLA、およびその他の同等のものをいくつか使用しました。私はそれらを使用するだけでなく、実稼働環境でこれらのアプリケーションを積極的に開発および保守してきました。

私は、実体オブジェクトが私たちの邪魔をしているという実戦テスト済みの結論に達しました.私たちの生活はそれらがなければずっと楽になるでしょう.

次の簡単な例を考えてみましょう。アプリケーション内の特定のページが正しく機能していないというサポートの電話を受けました。フィールドの 1 つが本来あるべきように永続化されていない可能性があります。私のモデルでは、問題を見つけるために割り当てられた開発者は、ちょうど 3 つのファイルを開きます。ASPX、ASPX.CS、およびストアドプロシージャを含む SQL ファイル。ストアドプロシージャ呼び出しのパラメーターが欠落している可能性があるこの問題は、解決するのに数分かかります。しかし、どのエンティティモデルでも必ずデバッガーを起動し、コードのステップ実行を開始すると、Visual Studio で 15 ～ 20 個のファイルが開かれることになります。スタックの一番下に降りる頃には、どこから始めたか忘れてしまいます。私たちは一度に多くのことを頭の中に入れておくことができます。ソフトウェアは、不要なレイヤーを追加することなく、信じられないほど複雑です。

開発の複雑さとトラブルシューティングは、私の不満の 1 つの側面にすぎません。

次に、スケーラビリティについて話しましょう。

開発者は、データベースとやり取りするコードを作成または変更するたびに、データベースへの正確な影響を徹底的に分析する必要があることを認識していますか? 開発コピーだけでなく、本番環境の模倣を意味するため、オブジェクトに必要な列を追加すると、現在のクエリプランが無効になり、1 秒で実行されていたレポートが 2 分かかることがわかります。選択リストに単一の列を追加したためですか？また、現在必要なインデックスが非常に大きいため、DBA がファイルの物理レイアウトを変更する必要があることがわかりましたか?

抽象化によって物理的なデータストアから離れすぎると、スケーリングが必要なアプリケーションに大混乱が生じます。

私は熱狂者ではありません。Linq から Sql、ADO.NET EF、Hibernate、Java EE などへの強力な推進力があるため、私が間違っているかどうかは確信できます。それが何であるか、そしてなぜ私が自分の考えを変える必要があるのかを本当に知りたい.

[編集]

この質問が突然再びアクティブになったようです。そのため、新しいコメント機能が追加されたので、いくつかの回答に直接コメントしました。返信ありがとうございます。これは健全な議論だと思います。

エンタープライズアプリケーションについて話していることをもっと明確にするべきだったでしょう。たとえば、誰かのデスクトップで実行されているゲームやモバイルアプリについては、コメントできません。

いくつかの同様の回答に応えて、私がここで一番上に挙げなければならないことの1つは、直交性と関心の分離がエンティティ/ ORMに移行する理由としてしばしば引用されることです。私にとって、ストアドプロシージャは、私が考えることができる懸念の分離の最良の例です。ストアドプロシージャ以外のデータベースへのアクセスをすべて許可しない場合、ストアドプロシージャの入力と出力を維持している限り、データモデル全体を理論的に再設計しても、コードを壊すことはありません。これらは、コントラクトによるプログラミングの完璧な例です (「select *」を避け、結果セットを文書化する限り)。

この業界に長く携わっていて、寿命の長いアプリケーションを扱ってきた人に尋ねてみてください。データベースが存続している間に、いくつのアプリケーションと UI レイヤーが行き来しましたか? データを取得するために SQL を生成する 4 つまたは 5 つの異なる永続レイヤーがある場合、データベースを調整してリファクタリングするのはどれほど難しいでしょうか? あなたは何も変えることはできません！ORM または SQL を生成するコードは、データベースをロックします。

score 59 · Accepted Answer

アプリケーションの「ロジック」がどれほど複雑で、どこに実装したかにかかっていると思います。すべてのロジックがストアドプロシージャにあり、アプリケーションがそれらのプロシージャを呼び出して結果を表示するだけの場合、エンティティオブジェクトの開発は時間の無駄です。しかし、オブジェクトが相互に豊富な相互作用を持ち、データベースが単なる永続メカニズムであるアプリケーションの場合、それらのオブジェクトを持つことには価値があります。

したがって、万能の答えはないと思います。開発者は、オブジェクト指向になりすぎると、解決するよりも多くの問題を引き起こす場合があることに注意する必要があります。

score 27 · Accepted Answer

理論的には、非常にまとまりがあり、疎結合の実装が進むべき道であると言われています。

ですから、あなたはそのアプローチ、つまり懸念の分離に疑問を抱いていると思います。

私の aspx.cs ファイルは、データベースと対話し、sproc を呼び出し、IDataReader を理解する必要がありますか?

チーム環境では、特にアプリケーションの aspx 部分を扱う技術者が少ない場合、これらの人々がこの部分に「触れる」ことができる必要はありません。

ドメインをデータベースから分離することで、データベースの構造的な変更から保護されます。これは良いことでしょうか? 確かにデータベースの有効性は絶対に重要です。そのため、その分野に最も優れた人が、システムの残りの部分にできるだけ影響を与えずに、その分野を 1 か所で処理できるようにします。

あなたのアプローチを誤解していない限り、データベースの 1 つの構造上の変更が、アプリケーションの表面に大きな影響を与える可能性があります。この関心の分離により、私と私のチームはこれを最小限に抑えることができます。また、チームの新しいメンバーは、このアプローチをよりよく理解する必要があります。

また、あなたのアプローチは、アプリケーションのビジネスロジックがデータベースに存在することを推奨しているように見えますか? これは私には間違っているように感じます.SQLはデータのクエリに非常に優れていますが、ビジネスロジックを表現することはできません.

興味深い考えですが、aspx の SQL から一歩離れているように感じますが、これは、私の悪い古い非構造化 ASP 時代から、私を恐怖で満たします。

score 26 · Accepted Answer

理由の 1 つは、ドメインモデルをデータベースモデルから分離することです。

私がやっていることは、テスト駆動開発を使用しているため、最初に UI レイヤーとモデルレイヤーを作成し、データレイヤーをモックすることです。そのため、UI とモデルはドメイン固有のオブジェクトを中心に構築され、その後、これらのオブジェクトを使用しているテクノロジにマップします。データ層。データベース構造にアプリケーションの設計を決定させるのは悪い考えです。可能であれば、最初にアプリを作成し、それがデータベースの構造に影響を与えるようにします。その逆ではありません。

score 21 · Accepted Answer

私にとっては、データの保存方法にアプリケーションが関与することを望まないということです。私はおそらくこれを言うために平手打ちされるでしょう...しかしあなたのアプリケーションはあなたのデータではなく、データはアプリケーションのアーティファクトです。私のアプリケーションは、DataSets、DataTables、DataRowsなどのテクノロジーではなく、顧客、注文、アイテムの観点から考えてほしいと思っています。

私は常にある程度の結合があることに同意しますが、私は結合が下向きではなく上向きに達することを好みます。木の幹を変更するよりも、木の手足や葉を簡単に微調整できます。

クエリはアプリケーションの一般的なデータアクセスよりも少し厄介になる傾向があるため、レポート用にsprocを予約する傾向があります。

また、そのシナリオの早い段階で適切な単体テストを行うと、1つの列が永続化されないことは問題にならない可能性が高いと考える傾向があります。

score 16 · Accepted Answer

エリック、あなたは死んでいる。本当にスケーラブルで保守が容易で堅牢なアプリケーションの場合、唯一の本当の答えは、すべてのゴミを省き、基本に固執することです。

私は自分のキャリアと同様の軌跡をたどり、同じ結論に達しました。もちろん、私たちは異端者と見なされ、面白いと見なされています。しかし、私のものはうまく機能し、うまく機能します。

コードのすべての行を疑って見る必要があります。

score 10 · Accepted Answer

あなたが提案したのと同じような例で答えたいと思います。

私の会社では、製品用の単純なCRUDセクションを作成する必要があり、すべてのエンティティと個別のDALを作成しました。その後、別の開発者が関連するテーブルを変更する必要があり、彼はいくつかのフィールドの名前を変更することさえしました。フォームを更新するために変更しなければならなかった唯一のファイルは、そのテーブルのDALでした。

（私の意見では）エンティティがプロジェクトにもたらすものは次のとおりです。

直交性：1つのレイヤーでの変更は、他のレイヤーに影響を与えない場合があります（もちろん、データベースに大きな変更を加えると、すべてのレイヤーに波及しますが、ほとんどの小さな変更は影響しません）。

テスト容易性：データベースに触れることなくロジックをテストできます。これにより、テストのパフォーマンスが向上します（より頻繁にテストを実行できるようになります）。

関心の分離：大きな製品では、データベースをDBAに割り当てることができ、DBAはそれを最適化することができます。モデルを設計するために必要な知識を持つビジネスエキスパートにモデルを割り当てます。Webフォームなどの経験が豊富な開発者に個々のフォームを割り当てます。

最後に、ほとんどのORMマッパーがストアドプロシージャをサポートしていることを付け加えたいと思います。それがあなたが使用しているものだからです。

乾杯。

score 8 · Accepted Answer

このトピックについて、あなたは「噛むことができる以上に噛んでいる」かもしれないと思います. Ted Neward は、それを「コンピュータサイエンスのベトナム」と呼んだとき、軽薄ではありませんでした。

私が絶対に保証できることの1つは、他の無数のブログ、フォーラム、ポッドキャストなどで頻繁に証明されているように、この問題に関する誰の見方も変えないということです.

物議を醸すトピックについてオープンな議論や議論を行うことは確かに問題ありません。これは、両方の「側」が同意しないことに同意し、ソフトウェアの作成に取り掛かったほど何度も行われただけです。

双方についてさらに読みたい場合は、Ted のブログ、Ayende Rahein、Jimmy Nilson、Scott Bellware、Alt.Net、Stephen Forte、Eric Evans などの記事を参照してください。

score 7 · Accepted Answer

@Dan、申し訳ありませんが、それは私が探しているものではありません。私はその理論を知っています。「非常に悪い考えです」というあなたの声明は、実際の例によって裏付けられていません。私たちは、ソフトウェアをより短時間で、より少ない人数で、より少ない間違いで開発しようとしており、簡単に変更できる機能を望んでいます。私の経験では、あなたのマルチレイヤーモデルは、上記のすべてのカテゴリで否定的です。特に、データモデルを最後に行うことに関しては。物理データモデルは、初日から重要な考慮事項である必要があります。

score 4 · Accepted Answer

エンティティオブジェクトは、アプリケーション層でのキャッシュを容易にすることができます。データリーダーをキャッシュして頑張ってください。

score 4 · Accepted Answer

本当に興味深い質問です。正直なところ、エンティティが優れている理由を証明することはできません。しかし、なぜ私はそれらが好きなのか、私の意見を共有することができます. コードのような

void exportOrder(Order order, String fileName){...};

DB から、Web リクエストから、単体テストからなど、注文がどこから来たのかは関係ありません。DataRow を取得して、必要な列と必要な型を文書化する代わりに、このメソッドが必要なものをより明示的に宣言します。なれ。何らかの方法でストアドプロシージャとして実装する場合も同様です。DB に存在する必要はありませんが、レコード ID をプッシュする必要があります。

このメソッドの実装は、DB での正確な表示方法に基づくのではなく、注文の抽象化に基づいて行われます。私が実装したそのような操作のほとんどは、実際にはこのデータの保存方法に依存しません。一部の操作では、パフォーマンスとスケーラビリティの目的で DB 構造との結合が必要であることを理解していますが、私の経験では、それほど多くはありません。私の経験では、Person が String を返す .getFirstName() を持ち、Address を返す .getAddress() があり、address が .getZipCode() などを持っていることを知るだけで十分です。そのデータを格納するためにどのテーブルが関与しているかは気にしません。 .

追加の列区切りがパフォーマンスを報告する場合など、説明したような問題に対処する必要がある場合、タスクにとって DB は重要な部分であり、実際にできるだけそれに近づける必要があります。エンティティはいくつかの便利な抽象化を提供できますが、いくつかの重要な詳細を隠すこともできます。

ここでスケーラビリティは興味深い点です。膨大なスケーラビリティを必要とする Web サイト (facebook、livejournal、flickr など) のほとんどは、DB をできるだけ使用せず、スケーラビリティの問題がキャッシング、特に RAM の使用によって解決される場合、DB 禁欲的なアプローチを使用する傾向があります。http://highscalability.com/には興味深い記事がいくつかあります。

score 4 · Accepted Answer

あなたの質問はとても興味深いと思いました。
通常、アプリケーションのビジネスロジックをカプセル化するにはエンティティオブジェクトが必要です。このロジックをデータ層にプッシュするのは非常に複雑で不適切です。
これらのエンティティオブジェクトを回避するにはどうしますか? どのような解決策を考えていますか？

score 4 · Accepted Answer

エンティティオブジェクトには、抽象化と疎結合以外にも正当な理由があります。私が最も気に入っていることの 1 つは、DataReader や DataTable では得られない強力な型指定です。もう 1 つの理由は、適切なエンティティクラスを適切に使用すると、フィールド名を含む一連の文字列を使用するのではなく、コードを見ている人なら誰でも理解できるドメイン固有の用語にファーストクラスの構成を使用することで、コードをより保守しやすくすることができるからです。 DataRow のインデックス作成用。ストアドプロシージャは、多くのマッピングフレームワークが sproc にマップする機能を提供するため、ORM の使用とは完全に直交しています。

sprocs + datareaders が優れた ORM の代わりになるとは考えていません。ストアドプロシージャを使用する場合でも、呼び出し元のコードとは異なる型システムを使用するプロシージャの型シグネチャによって制約を受け、密結合されます。ストアドプロシージャは、追加のオプションやスキーマの変更に対応するために変更される場合があります。スキーマが変更される可能性がある場合にストアドプロシージャに代わる方法は、ビューを使用することです。オブジェクトをビューにマップし、ビューを変更したときに基になるテーブルにビューを再マップできます。

あなたの経験が主に Java EE と CSLA で構成されている場合、ORM に対する嫌悪感は理解できます。非常に軽量なフレームワークであり、主にデータベーステーブルとの 1 対 1 のマッピングである LINQ to SQL を見てみることをお勧めしますが、通常は本格的なビジネスオブジェクトにするためのわずかな拡張のみが必要です。LINQ to SQL では、入力オブジェクトと出力オブジェクトをストアドプロシージャのパラメーターと結果にマップすることもできます。

ADO.NET エンティティフレームワークには、データベーステーブルを相互に継承するエンティティクラスとして、または単一のエンティティに集約された複数のテーブルの列として表示できるという利点があります。スキーマを変更する必要がある場合は、実際のアプリケーションコードを変更せずに、概念モデルからストレージスキーマへのマッピングを変更できます。ここでも、ストアドプロシージャを使用できます。

アプリケーションのスケーラビリティの問題よりも、コードの保守性や開発者の生産性の低さ (たとえば、sproc の作成とアプリの作成との間のコンテキストの切り替えから発生する可能性があります) が原因で失敗する企業の IT プロジェクトのほうが多いと思います。

score 4 · Accepted Answer

また、実体とは何かという概念についても話し合う必要があります。この議論を読んでいると、ここにいるほとんどの人は、Anemic Domain Modelという意味でエンティティを見ているという印象を受けます。多くの人が、Anemic Domain Model をアンチパターンと見なしています。

豊富なドメインモデルには価値があります。それがドメイン駆動設計のすべてです。個人的には、オブジェクト指向は複雑さを克服する方法だと信じています。これは、技術的な複雑さ (データアクセス、UI バインディング、セキュリティなど)だけでなく、ビジネスドメインの複雑さも意味します。

ビジネス上の問題を分析、モデル化、設計、および実装するために OO 手法を適用できれば、自明ではないアプリケーションの保守性と拡張性に大きな利点があります。

エンティティとテーブルには違いがあります。エンティティはモデルを表す必要があり、テーブルはモデルのデータの側面を表すだけです!

データがアプリよりも長く存続するのは事実ですが、David Laribeeからの次の引用を考えてみてください。

このトピックに関するその他のリンク:

score 3 · Accepted Answer

また、両方のモデルを分離すると、アプリケーションを異なるデータベースサーバーまたはデータベースモデルで実行できるようになる可能性があるというダンの回答に追加したいと思います。

score 3 · Accepted Answer

複数の Web サーバーの負荷を分散してアプリをスケーリングする必要がある場合はどうすればよいでしょうか? すべての Web サーバーに完全なアプリをインストールすることもできますが、より良い解決策は、Web サーバーがアプリケーションサーバーと通信するようにすることです。

しかし、エンティティオブジェクトが存在しない場合は、あまり話題になりません。

モノリスが単純で内部的な短命のアプリケーションである場合、モノリスを書くべきではないと言っているのではありません。しかし、それが適度に複雑になるか、かなりの時間続くようになるとすぐに、優れた設計について真剣に考える必要があります。

これにより、メンテナンスの時間を節約できます。

アプリケーションロジックをプレゼンテーションロジックとデータアクセスから分離し、それらの間で DTO を渡すことにより、それらを分離します。それらが独立して変更できるようにします。

score 3 · Accepted Answer

質問:すべてのビジネスロジックがデータベースに閉じ込められている場合、切断されたアプリケーションをどのように処理しますか?

私が興味を持っている種類のエンタープライズアプリケーションでは、複数のサイトを処理する必要があり、そのうちのいくつかは切断された状態で機能できる必要があります。
ビジネスロジックがドメインレイヤーにカプセル化されており、さまざまなアプリケーションタイプに簡単に組み込むことができます。たとえばdll、ビジネスルールを認識し、必要に応じてローカルに適用できるアプリケーションを構築できます。

データベースのストアドプロシージャにドメイン層を保持する場合、データベースへの永続的な見通し線を必要とする単一タイプのアプリケーションに固執する必要があります。

特定のクラスの環境では問題ありませんが、エンタープライズアプリケーションの全範囲をカバーするわけではありません。

score 3 · Accepted Answer

comp.object に関するこの投稿が興味深いかもしれません。

私は同意または反対を主張しているわけではありませんが、興味深いものであり、このトピックに関連している (と私は思います)。

score 2 · Accepted Answer

私は最近、これと同じことについてよく考えています。私はしばらくの間CSLAのヘビーユーザーでしたが、「すべてのビジネスロジック（または少なくとも合理的に可能な限り）はビジネスエンティティにカプセル化されている」と言う純粋さが大好きです。

多くのビジネスソフトウェアの場合のように、データベースの設計がデータの操作方法と異なる場合、ビジネスエンティティモデルが多くの価値を提供することを私は見てきました。

たとえば、「顧客」のアイデアは、顧客テーブルのメインレコードと、顧客が行ったすべての注文、すべての顧客の従業員とその連絡先情報、および顧客とその子は、ルックアップテーブルから決定できます。ビジネスの観点からは、顧客の概念にはこれらすべてが含まれており、データベースに関係が適用される場合とされない場合があるため、開発の観点からは、単一のエンティティとして顧客と連携できることは非常に便利です。

「ビジネスルールがデータベースにない場合、それは単なる提案です」という引用に感謝しますが、ビジネスルールを適用するようにデータベースを設計するのではなく、効率的で高速かつ正規化されたデータベースを設計する必要があると思います。。

とは言うものの、他の人が上で述べたように、「完璧なデザイン」はなく、ツールは仕事に適合しなければなりません。しかし、ビジネスエンティティを使用すると、ビジネスロジックを変更する場所がわかっており、オブジェクトは直感的な方法で実際の概念をモデル化できるため、メンテナンスと生産性に非常に役立ちます。

score 2 · Accepted Answer

あなたが何を「エンタープライズアプリケーション」と考えているのか、よくわかりません。しかし、RDBMSが固定され、システムが内部または外部の他のシステムと相互運用可能である必要がない内部アプリケーションとして定義しているという印象を受けています。

しかし、基本的な CRUD 操作のためだけに各テーブルに 4 つのストアドプロシージャに相当する 100 個のテーブルを持つデータベースがあり、400 個のストアドプロシージャを維持する必要があり、厳密に型指定されていないため、タイプミスの影響を受けやすく、ユニットテストもできない場合はどうでしょうか。 . オープンソースエバンジェリストである新しい CTO を獲得し、RDBMS を SQL Server から MySql に変更したい場合はどうなりますか?

今日、エンタープライズアプリケーションであれ製品であれ、多くのソフトウェアが SOA を使用しており、Web サービスを公開するための要件がいくつかあります。少なくとも、私が関わっているソフトウェアはそうしています。あなたのアプローチを使用すると、シリアル化された DataTable または DataRows を公開することになります。現在、クライアントが .NET であり、内部ネットワーク上にあることが保証されている場合、これは許容できると見なされる場合があります。ただし、クライアントが不明な場合は、直感的な API を設計するように努める必要があり、ほとんどの場合、フルデータベーススキーマを公開したくないでしょう。Java 開発者に、DataTable とは何か、およびその使用方法を説明したくありません。また、帯域幅とペイロードサイズ、およびシリアル化された DataTables の考慮事項もあります。DataSets は非常に重いです。

ソフトウェア設計に特効薬はありません。それは、優先順位がどこにあるかに大きく依存します。私にとっては、ユニットテスト可能なコードと、どのクライアントでも簡単に使用できる疎結合コンポーネントにあります。

ちょうど私の2セント

score 2 · Accepted Answer

@jdecuyper、私がよく繰り返す格言の1つは、「ビジネスロジックがデータベースにない場合、それは推奨事項にすぎません」です。ポール・ニールソンが彼の本の中で言ったと思います。アプリケーション層と UI は行き来しますが、データは通常非常に長期間存続します。

エンティティオブジェクトを回避するにはどうすればよいですか? 主にストアドプロシージャ。また、ビジネスロジックは、意図しているかどうかにかかわらず、アプリケーションのすべてのレイヤーに到達する傾向があることも率直に認めます。ある程度のカップリングは本質的であり、避けられません。

score 2 · Accepted Answer

エリック、

あなたが望むフレームワーク/アプローチを選択することを誰も止めません。「データドリブン/ストアドプロシージャを利用した」パスに進む場合は、ぜひ行ってください。特に、それがアプリケーションを仕様どおりかつ時間通りに提供するのに本当に本当に役立つのであれば.

警告は（つまり、あなたの質問の裏返しです）、すべてのビジネスルールはストアドプロシージャにある必要があり、アプリケーションはシンクライアントにすぎません。

そうは言っても、アプリケーションを OOP で実行する場合も同じルールが適用されます。一貫性を保つ必要があります。OOP の原則に従います。これには、ドメインモデルを表すエンティティオブジェクトの作成が含まれます。

ここでの唯一の本当のルールは、一貫性という言葉です。DB 中心になることを誰も止めません。古い学校の構造化された (別名、関数型/手続き型) プログラムを実行することを誰も止めません。なんてこった、だれも COBOL スタイルのコードを実行するのを止めていない。しかし、ある程度の成功を収めたいのであれば、アプリケーションはこの道をたどると非常に一貫性がなければなりません。

score 2 · Accepted Answer

OO と RDB の間の距離の問題に、別の視点を提供したいと思います。それは、歴史です。

どのソフトウェアにも、ある程度現実を抽象化した現実のモデルがあります。現実のすべての複雑さを捉えることができるコンピュータープログラムはありません。プログラムは、現実から一連の問題を解決するためだけに作成されます。したがって、どのソフトウェアモデルも現実の縮小です。時々、ソフトウェアモデルは現実を強制的に縮小させます。たとえば、レンタカー会社に、青色で合金を使用している限り、どんな車でも予約してもらいたいのですが、あなたの要求がコンピューターに収まらないため、オペレーターは応じることができません。

RDB は、アカウンティングと呼ばれる情報をテーブルに入れるという非常に古い伝統に由来します。会計は紙で、次にパンチカードで、そしてコンピューターで行われました。しかし、会計はすでに現実の縮小です。会計は、人々にそのシステムに従うことを強いてきたので、それが現実として受け入れられるようになりました。そのため、会計用のコンピュータソフトウェアを作成するのは比較的簡単です。コンピュータが登場するずっと前から、会計には情報モデルがありました。

優れた会計システムの重要性と、あらゆるビジネスマネージャーから受け入れられることを考えると、これらのシステムは非常に高度なものになっています。現在、データベースの基盤は非常に強固であり、重要なデータを非常に信頼できるものに保持することをためらう人はいません。

現実の他の側面は、会計よりもモデル化するのが難しいことに人々が気付いたときに、オブジェクト指向が登場したに違いないと思います（会計はすでにモデルになっています）。OO は非常に成功したアイデアになりましたが、OO データの永続性は比較的未開発です。RDB/Accounting は簡単に成功しましたが、OO ははるかに大きな分野です (基本的に、会計以外のすべて)。

私たちの多くは OO を使いたいと思っていましたが、それでもデータを安全に保管したいと考えています。尊敬されている会計システムと同じ方法でデータを保存するよりも安全なことはありますか? それは魅力的な見通しですが、私たちは皆同じ落とし穴に陥ります。会計の伝統と地位の恩恵を受けてきたRDB業界による多大な努力と比較して、オブジェクト指向の持続性について考えるのに苦労した人はほとんどいません。

Prevayler と db4o はいくつかの提案です。私が聞いたことのないものは他にもあると思いますが、ハイバネーションなどのように報道の半分を占めているようには見えません。

オブジェクトを古き良きファイルに保存することは、マルチユーザーアプリケーション、特に Web アプリケーションでは真剣に受け止められていないようです。

OO と RDB の間の溝を埋めるための日々の闘いの中で、可能な限り OO を使用しますが、継承は最小限に抑えようとしています。SPはあまり使いません。高度なクエリは、経理のように見える面でのみ使用します。

キャズムが完全に閉じられたとき、私は喜んで驚いています. オラクルが「Oracle Object Instance Base」のようなものを立ち上げると、解決策が見つかると思います。本当にキャッチするには、安心できる名前が必要です。

score 1 · Accepted Answer

現時点ではそれほど時間はありませんが、頭のてっぺんから少し離れています...

エンティティモデルを使用すると、ストアドプロシージャインターフェイスで実行できる機能を超えて、データベース（およびその他の可能なシステム）に一貫したインターフェイスを提供できます。企業全体のビジネスモデルを使用することで、すべてのアプリケーションがデータに一貫して影響を与えることを確認できます。これは非常に重要なことです。そうしないと、悪いデータになってしまいます。これは単なる悪です。

アプリケーションが1つしかない場合は、そのアプリケーションやデータの大きさに関係なく、実際には「エンタープライズ」システムはありません。その場合、あなたはあなたが話しているのと同様のアプローチを使うことができます。将来システムを拡張することを決定した場合に必要となる作業に注意してください。

ただし、次の点に注意する必要があります（IMO）。

生成されたSQLコードは不良です（以下の例外）。申し訳ありませんが、多くの人が時間を大幅に節約できると思っていることは知っていますが、自分が記述できるコードよりも効率的なコードを生成できるシステムを見つけたことがなく、コードがひどいものであることがよくあります。また、使用されない大量のSQLコードを生成してしまうこともよくあります。ここでの例外は、ルックアップテーブルのような非常に単純なパターンです。しかし、多くの人がそれに夢中になります。
エンティティ<>テーブル（または必然的に論理データモデルエンティティ）。多くの場合、データモデルには、データベースにできるだけ近い形で適用する必要のあるデータルールがあります。これには、テーブルの行が相互にどのように関連するかに関するルールや、宣言型RIには複雑すぎる他の同様のルールを含めることができます。これらはストアドプロシージャで処理する必要があります。すべてのストアドプロシージャが単純なCRUDプロシージャである場合、それを行うことはできません。さらに、CRUDモデルは、ネットワークを介したデータベースへのラウンドトリップを最小化しないため、通常、パフォーマンスの問題を引き起こします。これは、多くの場合、エンタープライズアプリケーションの最大のボトルネックです。

score 1 · Accepted Answer

場合によっては、アプリケーションとデータレイヤーがそれほど緊密に結合されていないことがあります。たとえば、電話請求アプリケーションがあるとします。後で、電話の使用状況を監視する別のアプリケーションを作成して、a) より適切に宣伝し、b) 電話プランを最適化します。

これらのアプリケーションには、さまざまな関心事とデータ要件があり (データが同じデータベースから取得されたものであっても)、異なる設計を推進します。データベースにコードを駆動させると、コードベースは (どちらのアプリケーションでも) 完全に混乱し、維持するのは悪夢になる可能性があります。

score 1 · Accepted Answer

データストレージロジックから分離されたドメインロジックを持つアプリケーションは、あらゆる種類のデータソース (データベースなど) または UI (Web または Windows (または Linux など)) アプリケーションに適応できます。

あなたのデータベースにかなり行き詰まっていますが、あなたが使用している現在のデータベースシステムに満足している会社であれば、それは悪くありません. ただし、データベースは時間の経過とともに進化するため、企業が使用したいと考える非常に優れた新しいデータベースシステムが存在する可能性があります。データアクセスの Web サービス方式に切り替えたい場合はどうなるでしょうか (サービス指向アーキテクチャが時々行うように)。ストアドプロシージャをあちこちに移植しなければならない場合があります。

また、ドメインロジックは UI を抽象化します。これは、UI が進化し続ける大規模で複雑なシステムではより重要になる可能性があります (特に、常により多くの顧客を探している場合)。

また、ストアドプロシージャとドメインロジックの問題に対する決定的な答えがないことにも同意します。私はドメインロジックキャンプに属しています (そして、彼らは時間の経過とともに勝利していると思います)。精巧なストアドプロシージャは、精巧なドメインロジックよりも維持するのが難しいと考えているからです。しかし、それはまったく別の議論です

score 0 · Accepted Answer

さて、おもしろい議論をありがとうございました。私はStephenWaltherのASP.NETMVCFramework Unleashedを進めており、一種の哲学的演習として楽しんでいますが、彼のアプローチに伴う配管コードの量には多少驚いています。これはORMの使用に固有のものではありません-Railsはそのようなハウスキーピングの問題からあなたを解放することに誇りを持っていますが、私は本当に、アプリケーションと、RecordクラスをデータベースにマップするEntityRecordクラス。

彼の利点についての彼の見解は、テストが迅速に実行されるテスト可能なアプリケーションになってしまうことですが、率直に言って、実際にアプリケーションにあるコードを実行するために、テスト速度を交換したいと思います。テストをすばやく実行できるように、1日をゆっくりと過ごしたり、プロパティをコピーしたりする頃には、テストの尻尾がプログラマーの犬を揺さぶり始めていると思います。火の。

2番目に挙げた利点は、アプリケーションを取得して別のデータベースで実行できることです。ええ、わかりました。SalesForceのようなものを再販用に書いている場合、それは目標かもしれませんが、そこにあるアプリケーションの90％以上については、どうでしょうか。「It'saWonderfulLife」で、ジョージにお金の壺を渡した隣人を思い出し、「夫ができた場合に備えて、離婚のためにこれを貯金していた」と言った。必要になるまで書かないでください。

一方で、私はストアドプロシージャに対して実際的な反対意見を持っています。それは必ずしもそれらの使用に固有のものではありませんが、私が働いてきたいくつかの頭の悪い店の特徴です：彼らは時々私が書きたいコードの邪魔をするDBAを置きます。私はカウボーイではないと思うのが好きですが、反対に、テーブルにフィールドを追加するために国連委員会を召集する必要はありません。

score 0 · Accepted Answer

興味深い質問です。いくつかの考え：

すべてのビジネスロジックがデータベースにあるかどうかをどのように単体テストしますか？
データベース構造の変更、特にアプリの複数のページに影響を与える変更は、アプリ全体で変更するのに大きな手間がかかるのではないでしょうか。

score 0 · Accepted Answer

最近のエンタープライズソリューションでは、エンティティオブジェクトが強調されすぎていると思います。ビジネスレイヤー関数は、サービスレイヤーのサービス、またはUI固有の関数のUIレイヤーなどに属するため、含めることはできません。エンティティオブジェクトを使用すると、設計者はアプリケーションの設計に関してより適切に考えることができますが、必ずしもそうとは限りません。それらにすべてのアプリケーションロジックを含める必要があります。それらは、特定のルールとインターフェイスに従うダムオブジェクトである可能性があり、それらの上に他のレイヤーを構築し、レイヤー間のデータキャリアとして機能するために使用できます。

score 0 · Accepted Answer

正直なところ、フォームを介してデータを処理できるのであれば、それを試してみてください。しかし、物事が粘り気になると、単純化するために物事を構造化する方法を学ぶのが賢明です。

私はすべての答えを読んだわけではありませんが、一般的なポイントは厄介になります：

コードが繰り返されるバギーで不安定なコード
静的クラスがロードされた巨大な
クラス
ロジックはどこにでもあり
ます（aspx、静的メソッド、sql、トリガー）
複数の
オブジェクトと相互作用し、共通の機能を共有することは困難になります

ドメインとデータに関する限り。データは常に勝つと思います。クライアントにとって重要なのは機能です。それは機能しなければなりません。私は、時間通りに機能するものを提供するという原則に違反した場合、可能な場合はリファクタリングの支持者です。いつでも戻ってリファクタリングすることができます。

また、デバッガー、複雑なドメインについて簡単に説明します。非常に高度なOOP/ポリモーフィックコードで可能なすべてのアクロバットを理解していないため、多くの人がインターフェイスにぶつかって怖がっているようです。私は完全に理解しています、時々あなたは道に迷って思いとどまることができます。これが彼らがツールを作る理由です。私は1000行の巨大な方法よりも1000ファイルの解決策を恐れていません。そして、私は両方がそれを信じるかどうかを見てきました。

テストを作成する意思がある場合は、デバッガーやコードのステップピンについてそれほど心配する必要はありません。優れたツールを入手してバランスをとれば、上記のすべての問題を解決し、問題を回避するのに十分なだけシンプルに保つことができます。

score 0 · Accepted Answer

1 つの質問: データソースが Web サービスである場合はどうなるでしょうか。Web サービスを介して分散されたデータのみを使用してアプリケーションを作成します。私のデータソースが RDBMS である場合とは異なるパラダイムを使用してそれを記述する必要がありますか?

RDBMS から Web サービスに切り替えたらどうするかを尋ねているのではありません (内部ショップでは、そうはありそうにないため)。

プログラミングモデルは、RDBMS の場合とは大幅に異なりますか? そうであれば、保守性を考慮する必要があります。開発者が飛び込むすべてのアプリが異なるパラダイムを使用してプログラムされているとしたら、私の開発者はひどい時間を過ごすでしょう。

score 0 · Accepted Answer

特定の種類のアプリケーションを作成し、特定の問題を解決することに慣れているだけだと思います。「データベースファースト」の観点からこれを攻撃しているようです。データを DB に永続化する開発者はたくさんいますが、パフォーマンスは最優先事項ではありません。多くの場合、永続化レイヤーに抽象化を適用すると、コードが大幅に簡素化され、パフォーマンスコストは問題になりません。

何をしていても、それは OOP ではありません。それは間違っているわけではありません。OOP ではないだけです。あなたの解決策を他のすべての問題に適用しても意味がありません。

score 0 · Accepted Answer

私は、SQL によって駆動されるリレーショナルデータベースが、ActiveRecord パラダイムを使用するこれらのフレームワークと目的が少しでも一致しないかどうかを推測してきました。根本的な問題の 1 つは、AR (さらに言えば、優れた OO 設計) によって、ロジックを分解するように駆り立てられることです。また、SQL は単純にステートメントの分解に適していません。

データベースに isam 永続性モデルを使用するのは良い考えではないでしょうか。OO とのインピーダンス整合が向上します。テーブルとしてのデータの基本的な考え方についてのより多くの合意。オブジェクト指向永続性の従来のアーティファクトとより一貫性があります。1 つの良い例は、FK とその関連付けをより明示的にできることです。

RoR にはデータベーススラッグであるという担当者がいて、私はこの問題がその理由の大部分を占めているのではないかと考えています。

ActiveRecord の実装に isam データベースを使用しようとした人はいますか?

score 0 · Accepted Answer

それぞれのアプローチには強みがあります。特定の問題に対するそれらの適切性は、ケースバイケースで判断する必要があります。

他の人が指摘しているように、エンティティ (したがってオブジェクト指向) の設計は複雑なビジネスロジックを単純化すると心から信じています。しかし、私の意見では、エンティティベースの設計の最大の強みは、明確に定義された入力と出力によるモジュール性です。これは、データベースの外で、オブジェクト指向モデルを使用して実現する方が簡単です。以下で詳しく説明します。

私は Linux ユーザーです。Unix の哲学の 1 つのポイントは、開発者は「テキストストリームを処理するプログラムを作成する必要がある」ということです。これは、ユニバーサルインターフェイスであるためです。Linux は非常にテキスト中心であるため、これは Linux にも当てはまります。のような新しいことを達成するために、無関係なプロセスを連鎖させることができますgrep ^col /var/log/bim-sync | sed 's/.*alt:\([0-9]\{1,\}\).*/\1/g | xargs -I replstr bim-transcoder replstr。これらのプログラムはお互いを完全に認識していませんが、新しい目的を達成するために簡単に組み合わせることができます。これが可能な理由は、あなた (「接着剤」の作成者) が各プロセスの入力形式と出力形式を知っているからです。

さて、私は、テキストストリームがあらゆる場所で適切であるとは考えていません。テキストストリームは一般的ですが、普遍的ではありません。私の開発哲学は「入力と出力が明確に定義されたプログラムを書く」ことです。ここで話している入力/出力は、必ずしも標準の入力/出力ではなく、必ずしもテキストでもありません。コマンドラインプログラムへの引数、ネットワークソケット経由で送信される生のバイト、レイヤー間で渡されるメモリ内データ構造などである可能性があります。コードなど。古い入力-プロセス-出力の「ブラックボックス」の観点からソフトウェアを考えると、Unix のコマンドラインユーティリティのようにアプリケーションを構成することができます。

例として、オーストラリアのニューサウスウェールズ州のBirths, Deaths and Marriages向けのソフトウェアを作成しているとします。子供の出生届が届くと、オペレーターが詳細を入力し、署名されたフォームをスキャンして[送信] ボタンを押します。Submitボタンを押すと、コマンドが発行されます。RegisterBirthソフトウェアはコマンドの詳細 (生年月日、病院など) を検証し、BirthRegisteredイベントを発行します。このイベントには、分娩医、自然分娩か帝王切開か、帝王切開かどうか、緊急出産かどうか、生物学上の両親は誰かなど、出産に関する多くの詳細が含まれます。 . さまざまなコードがこのイベントに「プラグイン」できます。たとえば、1 つのコードで単純なinsert into person...SQL ステートメント、別のコード片が一連のNeo4j サイファーコマンドを発行して、生まれたばかりの赤ちゃんとその生物学的両親との関係を保存することができます。この 2 番目のコードは、階層的な「家系図」データの非常に高速なクエリを可能にします。このようなクエリは、隣接リストまたはネストされたセットのどちらを使用するかに関係なく、SQL データベースでは遅くなります (そしてより複雑になります) 。さらに別のコードでは、歴史的な理由から XML ファイルに保存されている、その月の緊急帝王切開の数に関する統計を更新できます。

モジュール性は、永続化メカニズムの抽象化にとどまりません。たとえば、FastCGIの「接着層」を記述して、アプリケーションを Web 対応にすることができます。「入力」HTTP 要求が Web サーバーによって受け入れられ、「出力」FastCGI 要求が「接着層」に発行されます。FastCGI の「接着層」はこれを入力として受け取り、アプリケーションに適した出力形式に変換します。アプリケーションは入力コマンドを受け入れ、イベントまたはエラーを発行します。これらは、他の「接着層」 (上記の SQL および Neo4j の例など) によって取得できます。

モジュール性は、ほぼあらゆる方向に継続できます。コマンドラインインターフェイスまたは GUI インターフェイスを使用できます。包括的な自動テストスイートを作成できます。サードパーティによってスクリプト化されるまで、アプリケーションを開くことができます。ここでの概念の多くは、Domain Driven Design、Command Query Responsibility Segregation、Event Sourcing、相互に関連する 3 つのパターンに関連しており、これらは信じられないほど強力であることがわかりました。

エンティティベースのアプローチを使用する場合、多くの関連アーキテクチャがあります。たとえば、Jeffrey Palermo によるOnion Architectureと、Alistair Cockburn によるPorts and Adapters (または Hexagonal Architecute) があります。これらすべてのアーキテクチャに共通しているのは、定義された入力と出力によるモジュール性と抽象化です。これらの入力/出力の境界が単一のプログラム内にあるかどうか、またはそれらが多くのプロセスやネットワークにまたがっているかどうかに関係なく.

エンティティベースのアプローチは、モジュール性と柔軟性を提供します。ただし、このアプローチには欠点があり、そのうちの 3 つが重要です。

まず初期投資が高い。つまり、このようなアプローチは、範囲が小さいプロジェクトには意味がありません。
第 2 に、作成しなければならないグルーコードの量が大きくなる可能性があります。グルーコードを書くのは面倒ですが、やりがいもあります。たとえば、アプリケーションがストレージバックエンドであるため、PostgreSQL と緩やかに統合されているとします。会社の取締役が、アプリケーションが Microsoft SQL Server をサポートする必要があると判断した場合、目標が期日までに予算内で達成されたときは、非常に満足 (そしてチームの士気を高める) ことになります。
第 3 に、私の経験から、エンティティベースのアプローチは、実装者の専門知識によっては、単純な SQL ソリューションよりも悪い場合があることがわかりました。たとえば、エンティティファーストのアプローチが、データベーステーブルのインメモリ表現にすぎないゲッターとセッターでいっぱいである場合、問題が解決されていないことを確認できます。このような場合、当然のことながら、開発者は「なぜ SQL を記述しないのか?」と疑問に思います。

参考文献:

score 0 · Accepted Answer

なぜエンティティオブジェクトで止まるのですか? エンタープライズレベルのアプリでエンティティオブジェクトの価値が見られない場合は、純粋に関数型/手続き型言語でデータアクセスを行い、それを UI に接続します。オブジェクト指向の「綿毛」をすべて切り取ってみませんか?

score 0 · Accepted Answer

エンティティオブジェクトがスケーラビリティとどのような関係があるのかわかりません。おそらく、ORM ツールの使用について話しているのでしょう。この場合は同意します。

私はスケーラビリティに非常に興味があります。エンティティオブジェクトは、高度にスケーラブルなアプリケーションを構築する際には決して邪魔になりませんが、正しい方法で構築する必要があります。つまり、ORM を使用して生成された DAL とは対照的に、手書きの DAL が必要です。実際、これが私が ORM を好まない理由です。手書きの DAL に勝るものはありません。LINQ も使用しません。多くの場所で大きなオーバーヘッドがあることを読んだからです。アプリ内のすべてのクエリを調整し、必要なインデックスを作成します。一部の ORM にコードを生成させません。

Entity オブジェクトによってコードの保守が難しくなるという意見には同意しません。実際、このアーキテクチャの全体的な目的は、コードの保守と変更を容易にすることであり、これが実際に私が見たものです。長い間（3層またはn層アーキテクチャを使用していませんでした）、私が話していることを知っています。

また、キャッシングには Entity オブジェクトが必要です。Entity オブジェクトを使用しない場合、アプリケーションでデータをどのようにキャッシュするのだろうか。データセットまたはデータテーブルを使用しますか?

score 0 · Accepted Answer

私は最近、この質問に出くわしました。この質問はかなり古いものであり、多くの回答があることに気づき、私の回答は一度も見られないことが多いことを理解しています. それでも、ここにコメントを残しておきたいと思います。

私はこの問題を 3 つの側面から見ていきます。しかしその前に、10 人中 8 人のプログラマーが、命令型/OO 設計の世界 (C/C++、JAVA、C# など) から来たプログラマーは、最適化された効率的な SQL コードの書き方を知りません。私の経験上、アプリケーション開発とSQL開発の両方をこなせる人は珍しいです。

そうは言っても、この質問を見るために3つの側面を挙げたいと思います。

1 つ目:プログラムではなく、組織階層による関心の分離。

率直に言って、この世界にはさまざまな種類の「企業」があり、それぞれに歴史と哲学によって異なる独自の組織階層があります。私が一緒に働いた特定の会社では、プログラマーはデータベースを変更したり開発したりすることができませんでした。データベース API (つまり、SQL サーバーのストアドプロシージャ) を読み取って使用できますが、データベースを直接読み取ることはできず、クエリやストアドプロシージャを書き込むことはできません。

データベース要求 (データまたは機能) は、別の役割であるデータアーキテクトに委任する必要があります。彼女/彼は、データベースの開発と、場合によっては保守を担当します。(ただし、保守部分は DB 管理者の仕事である必要があります。) そのような環境では、ストアドプロシージャは消耗品にすぎません。PROD 環境のストアドプロシージャのソースでさえ暗号化され、プログラマは SP のソースを見ることができません。

ただし、他の一部の組織では、プログラマーは、インターフェイス、ミドルウェア、データストレージを含むすべての側面の開発を行うことが期待されています。これが大多数のケースです。

これらの 2 つのシナリオ (最初のシナリオはかなり極端ですが現実的ですが) では、著者の質問をどのように見るかに影響します。最初のケースでは、作成者はデータアーキテクトの役割に同意すると思いますが、組織内のデータベース以外のプログラマーは非常に軽蔑するでしょう。ただし、2 番目のケースでは、多くの開発者が適切な SQL コードの書き方を知らない (そして、一般的にそれを処理することも好まない) という以前の免責事項があるため、単純なアプローチである ORM を選択するのが自然です。

第二に: データベースの役割:さまざまな解釈に対応した純粋なデータストレージ、または定義済みの情報スキームの提供者?

定義: 「データ」はrawであり、「情報」は解釈されます。

多くの現実の状況では、データベースは純粋なデータストレージとのみ見なされます。これにはデータロジック (リレーショナルデータの整合性など) が含まれる場合がありますが、ビジネスロジック(たとえば、データの性質のためではなく、ビジネスのこの特定のセクションがどのように機能するかという理由でデータに適用される数式) は含まれません。

私が一緒に働いた前述の組織では、1 つのデータベースに、顧客のさまざまな財務情報が格納されています。まず、顧客の財務状態に関する指標を計算する数式は 1 つしかなく、この数式は、数式に基づく顧客のステータスと共に、データベースのストアドプロシージャ内に格納されます。しかし、政府は過去数年間、規則を変更し続けたため、政府に対応するためにさらに多くの公式が作成されました。

したがって、問題: 組織内の各支店は、独自の異なるプログラミング部門 (および各支店間の組織間ビジネスはほとんどない) を持ち、同じ財務データセットを使用しますが、異なる数式と演算を使用します。

この場合、数式をデータベースに格納するという元のモデルは、メンテナンスと社内政治の地獄をもたらしました。最初、データアーキテクトは変更に対応するために型付きストアドプロシージャを作成しましたが、すぐに組織はこのモデルに問題を抱え始めました。HQ は、各ブランチが独自のフォーミュラセットを維持し、そのブランチ以外の誰もが所有するフォーミュラを知る必要があると判断しました。この場合、データアーキテクトはすべての公式を知っていましたが、それは本社のポリシーにうまく適合しませんでした。数式を変更するペースが速いため、各ブランチ間のテストの効率性の問題も生じました。これは、すべての数式の微調整がデータアーキテクトを通過する必要があったためです。

この場合、組織はかなり深刻な問題に直面します。データベースは解釈された情報を提供するべきか、それとも意味のないデータのみを提供するべきか?

これは、第 3 の側面に飛び込むための良い方法です。

3番目: イデオロギー戦争:単一 vs 多目的、モノリシック vs モジュール?

前述の例は、データが多目的に使用されていることを明確に示しています。データは、すべてのブランチで同じままでしたが、さまざまなシナリオでさまざまな解釈と使用法を持っていました。そして、これが私の見解です。

あなたのデータベースは、本質的に多目的であり、パフォーマンスは大きな問題ではないデータを保存して提供していますか?

はいの場合、データベースはデータを提供するだけに縮小し、データの整合性に関係のないロジックは別の場所に保存する必要があります。これはよりモジュール化されたアプローチです。他の人は、必要な操作と解釈をプラグインできますが、SQL ではプラグインできません。

質問の一部が否定的である場合 (つまり、単一の目的である、またはパフォーマンスが大きな懸念事項である)、オフィスの政治が邪魔されないと仮定すると、多数のものをデータベースに入れるモノリシックなアプローチと言えます。結構です。好むと好まざるとにかかわらず、それはイデオロギーの選択になります。

著者は、質問を書いて編集する際に、モノリシックなアプローチの意見を支持しているという印象があります。私はこれをケースバイケースで検討しますが、一般的に、私はそのようなアプローチをとっています：

シンプルな CRUD だけ: ORM
データに基づく数式とワークフロー: データベースではなくミドルウェア (CSLA など) (パフォーマンスが懸念される場合を除く)
レポート: 間違いなくデータベースにある (パフォーマンス上の理由から)

上記は私の2セントです。

score 0 · Accepted Answer

私のアプリ内のオブジェクトは、データベースに 1 対 1 で関連付けられる傾向がありますが、sprocs ではなく Linq To Sql を使用すると、複雑なクエリの記述がはるかに簡単になり、特に遅延実行を使用してそれらを構築できることがわかりました。たとえば、Images.User.Ratings where などの r から。これにより、SQL でいくつかの結合ステートメントを作成しようとする手間が省けます。

score 0 · Accepted Answer

良い質問！

私がむしろ気に入っているアプローチの 1 つは、特定のコンテキストに関連するオブジェクトのインスタンスを発行するイテレーター/ジェネレーターオブジェクトを作成することです。通常、このオブジェクトは基礎となるデータベースアクセスの一部をラップしますが、使用するときにそれを知る必要はありません。

例えば、

AnswerIterator オブジェクトは AnswerIterator.Answer オブジェクトを生成します。内部では、SQL ステートメントを繰り返し処理してすべての回答を取得し、別の SQL ステートメントを使用して関連するすべてのコメントを取得しています。しかし、反復子を使用するときは、このコンテキストの最小限のプロパティを持つ Answer オブジェクトを使用するだけです。少しのスケルトンコードを使用すると、これを行うのはほとんど簡単になります。

これは、作業するデータセットが巨大な場合にうまく機能することがわかりました。正しく実行すると、テストが比較的簡単な小さな一時的なオブジェクトが得られます。

これは基本的に、Database Access に関するものよりも薄いベニアですが、必要に応じて抽象化するという柔軟性が得られます。

score 0 · Accepted Answer

ストアドプロシージャを支持する「データベースをロックする」という議論に戸惑っています。ActiveRecord モデルを MySQL から Postgres、SQLite に移行できます。ありがとうございます。それらをすべて書き直したくない限り、ストアドプロシージャベースのものではそれを行うことができませんでした。

データベーススキーマを石でロックしているという意味だと思います。その議論はより興味深いものです。ユニットテストとコードカバレッジが最小限のアプリケーションの観点からある程度議論されていると思います.コードを変更しないアプリケーションは、「何か」を壊すのではないかという純粋な恐怖からです.

ただし、ストアドプロシージャベースのシステムに関する私の経験は最小限です。大規模なアプリケーションでは、すべてのデータ関係をどのように管理しているのでしょうか? あるページでは、写真付きの製品を紹介しています。別のページでは、製品とそれを作成したユーザーを示しています。別のページでは、製品とそれに関するコメントを示しています。別のページで、写真のない製品を仕様の表と結合して表示する必要があります....などなど。多くの関係を持つデータモデルがあります。すべての組み合わせに対してストアドプロシージャを作成しないと思いますか? DRY の原則は、私が心配しているものです。リレーションシップを再左結合 (効果的に再コーディング) している場合に、いくつのクエリを作成していますか? また、スキーマのロックについて話している間に、いくつのストアドプロシージャを書き直す必要があるでしょうか。

score 0 · Accepted Answer

セットに関連する操作などの一部のロジックは、ストアドプロシージャでより適切に表現される傾向があります。しかし、多くの分岐と条件を持つアルゴリズムをプログラミングコードで表現するのが最適な場合もあります。スクリプトアクションのランタイム関数をサポートするコマンドの解析に使用される文法は、ストアドプロシージャに実装できません。

ストアドプロシージャに見られる 1 つの弱点は、アプリケーション内の新しいリストまたはグリッドに対して新しいストアドプロシージャを取得する傾向があることです。さらに悪いことに、1 つのストアドプロシージャですべてを管理し、10 個のパラメーターと case ステートメントでそれらをさらに定義します。さらに、ストアドプロシージャは巨大になり、デバッグがさらに難しくなります。

そうは言っても、あなたが見つけた理由でORMが何度も邪魔になる可能性があることはあなたと一緒です. 最終的には、テクノロジーをどのように支配するかにかかっています。

sql - エンティティ オブジェクトが必要な理由

41 に答える 41

Related

Reference

sql - エンティティオブジェクトが必要な理由