0

次の点について、データ モデリングと SQL (OOP と Select ステートメント) の概念について意見をお聞かせください。

<php? | <% | <#

Class Country{
     _name:String;
     _language:String;      
}

Class Estate{
     _name:String;
     _country:Country;
}

?> | % | #>

私が取得しようとしているポイントは、単純な親子関係です。現在、ExtJS + PHP と JSF 2.0 (コンバーターを使用する Java) での作業を見てきましたが、DAO (データ アクセス オブジェクト) が次のように定義されているのを見るのは非常に一般的です。

Abstract class CountryDAO{
     public function getCountry();//This function returns an ArrayList.
     public function getCountryById(countryId:Integer);//This function returns a Country Object;
     ...
}

Class EstateDAO{
     public function getEstate(){
         $sql = "SELECT * FROM tbl_estate";
         //[your favorite way to comunicate with the database here]
         //Declare an ArrayList or something to store the result:
         $arrayList;
         while($result = $ResultSet.next()){
              $obj = new Estate();
              $obj->name = $result['name'];
              $obj->Country = new CountryDAO().getCountryById($result['country_id']);
              $arrayList->addItem($obj);
         }
     }
}

言語の構文を混在させて申し訳ありません。言語に執着しすぎないようにしています。概念だけです

ここで私の考えを締めくくります。理論によれば、それは正しい概念です。個人的には、それが物事の論理であるため、それに反対するのは正しくないと思います. しかし、実際には、現実の世界はあなたが望むように輝くことはありません。

10 個のエステートがある場合、11 個の SQL ステートメントがハード ディスク レベルで実行されます (オペレーション システムの理論によれば、これはあらゆる種類の保存メモリの中で最も遅いものです)。

100 個のエステートがある場合、101 個の SQL ステートメントが実行されます。

エステートがn 個ある場合、 n+1 個のSQL ステートメントが実行されます。

最後のポイント: 何千ものレコードを持つ可能性のあるデータ エンティティをモデル化している場合、これは非常に苦痛になる可能性があると思います。そのような考えから、Flex + PHP を使用する際に、この種の設計ロジックを使用することを拒否しました。しかし今、Flex と ExtJS の両方をビューアーとして、PHP をサーバーサイドとして持つアプリケーションを構築しようとしているので、取るに足らない理由で最も難しいパスを選択していないことを確認したいだけです。この MVC/OOP ロジックを尊重しない方が安全ですか? 私は誇張していますか？OOP での SQL 対データ モデルについてどう思いますか?

ありがとう。

4

2 に答える 2

1

DB テーブルに直接マップする DAO 実装には近づかないことをお勧めします。代わりに、データ マッパーパターンを調べる必要があります。

基本的には、モデル レイヤー内で、ビジネス ロジックをドメイン オブジェクトに分離し、DB インタラクションをデータ マッパーに分離するという考え方です。このように、アイテムのコレクション (100 の不動産の詳細など) を取得する必要がある場合、マッパーは 1 つまたは 2 つのクエリのみを実行し、コレクションを処理するドメイン オブジェクトにデータをダンプします。

また、各マッパーは複数の DB テーブルを簡単に処理できます。マッパーの目標は、ドメイン オブジェクトを取得し、それをストレージと連携させることです。ドメイン オブジェクトが 1 つのテーブルしか使用できないという法律はありません。

いずれにせよ、MVC デザイン パターンは、情報の保存場所とは関係ありません。ユーザー インターフェイスとドメイン ビジネス ロジックの分離のみを扱います。SQL インタラクション (SQL データベースを使用し、他のデータ ソースを使用しない場合) は、モデル レイヤーの奥深くに埋もれています。

この記事を読むことを強くお勧めします: GUI Architectures by Martin Fowler。

また、主に PHP を扱っている場合は、このコメントが役に立つかもしれません。

于 2012-07-07T04:36:53.620 に答える
0

あなたは両方の世界の長所を持つことができます。オブジェクトをメモリに保存する方法で保存する必要はありません。保存する場合でも、追加のオブジェクトをモデル化して、効率的な方法で保存できるようにすることができます。

Class Country{
     _name:String;
     _language:String;      
}
Class Estate{
     _name:String;
     _country:Country;
}

次のものを作成できます。

Class EstateWithCountryInformation{
     _estateName:String;
     _countryName:String;
     _language:String;      
     getEstate();
     getCountry();
}

そして、テーブルCountryとEstateWithCountryInformationのみがあります。そうすれば、1回のクエリで必要なものを取得できます。Estate情報だけをクエリする必要がある場合は、EstateWithCountryInformationテーブルから取得することもできます。または、データベースビューを作成してそのテーブルをシミュレートすることもできます。

DBにアクセスするために何を使用するかはわかりませんが、高度なマッピングオプションを備えたORMをいくつか知っています。これにより、最初に定義したクラスを取得し、テーブルなどのEstateWithCountryInformationに自動的にマッピングできます。エステート、そして後で新しいCountryDAO（）。getCountryById（）を呼び出すと、情報がメモリにキャッシュされるため、追加のDBアクセスは行われません。

于 2012-07-07T04:15:28.490 に答える