2

Zend Frameworkでのデータアクセスに関するいくつかのチュートリアルや書籍を見ると、ほとんどの人がモデル（Active Record Pattern）またはコントローラー内でデータアクセスを行っているように見えます。私はそれに強く反対します。したがって、データアクセス層（DAL）を使用して、ドメイン層に「ZFのもの」を含めないことで移植性を維持したいと考えています。私は周りを検索しましたが、私が望んでいたものを正確に見つけることができませんでした。注意：私はZFを初めて使用します。

DAL構造

したがって、最初の問題は、データアクセス層をどこに配置するかです。確かにlibraryフォルダー内に配置してオートローダーに名前空間を追加することはできますが、それは私のアプリケーションに固有であるため論理的ではないようです（したがってapplicationsフォルダーは適切です）。モジュール構造を使用しています。私は以下の構造を使用することを考えています：

/application/modules/default/dal/

ただし、コントローラー内のクラスにアクセスできるように（includes / requireを使用せずに）このフォルダーをインクルードする方法がわかりません。誰かがこれを達成する方法を知っているなら、それは素晴らしいでしょう！もちろん、他のアイデアも歓迎します。

アイデアは、コントローラーがデータアクセスオブジェクト（DAO）と対話するようにすることです。次に、DAOは、コントローラーに返すことができるモデルを使用します。これを行うことで、モデルをそのままにしておくことができます。

実装

他の言語では、以前にモデルごとにDAOを実装しましDAL_Userた。その結果、DAOクラスが非常に多くなりました。これを行うためのよりスマートな方法はありますか（単一のクラスを使用することは外部キーでは簡単ではないようです）？

また、DAOクラスをZFに実装する方法についての提案もいただければ幸いです。私はデータベースの相互作用に利用できるすべてのコンポーネントについて読むのにそれほど多くの時間を費やしていないので、どんなアイデアでも大歓迎です。標準のPDOよりも賢いものがあると思います（ただし、おそらく内部でPDOを使用します）。ネームドロッピングで十分です。

多くの質問でごめんなさい。正しい方向にプッシュする必要があります。

4

2 に答える 2

4

を扱うときに最初に考慮しなければならないことData Access Layerは、このレイヤーにはサブレイヤーもあるということです。最新のフレームワークで「dal」と呼ばれるフォルダーを見つけるのは珍しいことです (私は Zend Framework と Symfony の両方をベースにしています)。 ）。

次に、についてですが、デフォルトでは Zend Frameworksはそれを実装していないActiveRecordことに注意してください。チュートリアルのほとんどは、新しい概念を教える最も簡単な方法をとっています。単純な例では、ビジネス ロジックの量は最小限であるため、別の複雑なレイヤー (データベースとモデルのオブジェクト間のマッピング) を追加する代わりに、Table Data GatewayとRow Data Gatewayの 2 つの基本パターンで (モデル)を構成します。初心者が始めるには十分な情報です。domain layer

それを分析すると、 ActiveRecord とRow Data Gatewayのパターンの間にいくつかの類似点があることがわかります。主な違いは、ActiveRecord オブジェクト (永続エンティティ)がビジネス ロジックを実行し、Row Data Gatewayはデータベース内の行のみを表すことです。データベース行を表すオブジェクトにビジネス ロジックを追加すると、それはActiveRecordオブジェクトになります。

さらに、Zend Frameworkクイック スタートのドメイン モデル セクションに続くと、データ マッパー パターンを使用する 3 番目のコンポーネントがあることがわかります。

そのため、主な目的がDALビジネス オブジェクト (モデル) とストレージの間でデータをマップすることである場合、このタスクの責任は次のようにデータ マッパーに委任されます。

class Application_Model_GuestbookMapper
{

    public function save(Application_Model_Guestbook $guestbook);

    public function find($id);

    public function fetchAll();

}

これらのメソッドは と対話しDatabase Abstraction Layer、ドメイン オブジェクトにデータを入力します。この行に沿った何か:

public function find($id, Application_Model_Guestbook $guestbook)
{

    $result = $this->getDbTable()->find($id);

    if (0 == count($result)) {

        return;

    }

    $row = $result->current();

    $guestbook->setId($row->id)

              ->setEmail($row->email)

              ->setComment($row->comment)

              ->setCreated($row->created);

}

ご覧のとおり、はテーブル データ ゲートウェイ パターンを使用するZend_Db_TableインスタンスData Mappersと対話します。一方、Row Data Gateway パターンを実装するZend_Db_Table_Rowのインスタンスを返します(これはデータベースの行を表すオブジェクトです)。$this->getDbTable->find()

ヒント: エンティティdomain object自体は、DataMapper の find() メソッドによって作成されたものではありません。代わりに、オブジェクトの作成はファクトリのタスクであり 、いわゆる 依存関係逆転の原則を達成するために依存関係を注入する必要があるという考え方です。 (DIP) (SOLID 原則の一部)。しかし、それは別の主題であり、質問の範囲外です。次のリンクにアクセスすることをお勧めしますhttp://youtu.be/RlfLCWKxHJ0guestbook

マッピングはここから始まります：

$guestbook->setId($row->id)
          ->setEmail($row->email)
          ->setComment($row->comment)
          ->setCreated($row->created);

これまでのところ、主な質問に答えたと思います。構造は次のようになります。

application/models/DbTable/Guestbook.php
application/models/Guestbook.php
application/models/GuestbookMapper.php

したがって、ZF クイック スタートのように:

class GuestbookController extends Zend_Controller_Action
{

    public function indexAction()

    {
        $guestbook = new Application_Model_GuestbookMapper();

        $this->view->entries = $guestbook->fetchAll();

    }

}

データマッパー用に別のフォルダーが必要になる場合があります。変更するだけです：

application/models/GuestbookMapper.php

に

application/models/DataMapper/GuestbookMapper.php

クラス名は

class Application_Model_DataMapper_GuestbookMapper

domain model objectsモジュールに分割したいことがわかりました。それも可能です。必要なのは、モジュールの ZF のディレクトリと名前空間のガイドラインに従うことだけです。

最後のヒント: 私は独自のデータ マッパーのコーディングに多くの時間を費やしてきましたが、アプリケーションが多数の相関エンティティで成長する場合、オブジェクト マッピングを維持するのは悪夢であることに最終的に気付きました。(つまり、ユーザー オブジェクトへの参照を含むアカウント オブジェクト、ロールを含むユーザーなど) この時点でマッピングを記述するのはそれほど簡単ではありません。したがって、真のオブジェクト リレーショナル マッパーが本当に必要な場合は、まずレガシー フレームワークがそのようなタスクをどのように実行するかを調べ、おそらくそれを使用することを強くお勧めします。ですから、 Doctrine 2で少し時間を割いてください。これは、 DataMapper パターンを使用したこれまでで最高の (IMO) の 1 つです。

それでおしまい。/dalディレクトリを使用して DataMappers を保存することもできます。名前空間を登録するだけで、オートローダーがそれを見つけることができます。

于 2012-08-23T06:40:25.403 に答える
0

私の意見では、モデルごとに (データベースへのアクセスだけでなく) ゲートウェイの抽象化が必要です。DAO だけでは不十分です。ある時点でクラウドからデータを取得する必要がある場合はどうしますか? これは急速に現実のものになりつつあります。ゲートウェイ ロジックを汎用的なものに抽象化し、それをデータベースを使用して実装すると、両方の長所を活かすことができます。

特定のゲートウェイ インターフェイスの実装では、選択した場合、汎用データ マッパーを使用できます。私は小さな会社で働いており、常に PDO を使用して実装を作成しています。これにより、データベースに十分に近づくことができ、必要になる可能性のある興味深い SQL を処理できますが、非常に抽象化されたインターフェイスをサポートできます。

Zend Framework はまったく使用していません。ゲートウェイ インターフェイスの実装に役立つデータ マッパー ツールがあるかどうかはわかりません。

于 2012-08-22T17:14:13.607 に答える