0

コードにOOPと依存性注入をより適切に実装しようとしていますが、以下の問題が発生します。

私は、雇用主と会社が関与しているクライアントにサービスを提供します（対応するモデル、マッパー、データベーステーブルを使用）。

class Service
{
    protected $clientId;
    protected $client;
    protected $employerId;
    protected $employer;
    protected $companyId;
    protected $company;

    public function setClient(Client $client)
    {
       $this->client = $client;       
    }

    public function setEmployer(Employer $client)
    {
        $this->employer = $employer;
    }

    public function setCompany(Company $company)
    {
        $this->company = $company;
    }

    // more
}

Serviceオブジェクトを取得するには、最初にデータベースからclientIdを返すServiceオブジェクトをインスタンス化します。clientIdを使用して、データベースに再度アクセスすることを含むClientオブジェクトをインスタンス化します（そしてそれをサービスにアタッチします）。雇用主と会社についても同じです。

結合を使用してデータベースからサービス、クライアント、雇用者、会社を一度に取得することもできますが、それではマッパーがより複雑になります。たとえば、クライアント、雇用主、企業はすべて住所を持っているので、これらの列にエイリアスを付けて、それぞれのモデルにマッピングする必要があります。これは、各テーブルからすべての列を個別に取得し、それらを各モデルに個別にマップして（たとえば、下線付きの列をZFキャメルケースに変換するロジックを使用して）、クライアント、雇用者、および会社のマッパーを再利用するよりもクリーンではありません。

ベストプラクティスの解決策はありますか、それとも個人の好みや状況（パフォーマンスと保守性）次第ですか？

4

1 に答える 1

1

まず、PHPの依存性注入に関するすばらしい記事があります。これはチェックアウトする価値があると思います。第二に、あなたの質問は実際には依存性注入に関するものではありません。あなたが持っている主な質問はすべて、データベースにクエリを実行する回数に関するものだからです。

オブジェクトをServiceに注入する場合、それらを一度に呼び出すか、次々に呼び出すかは実際には問題ではありません。本当の問題は、「データベースを複数回ヒットする余裕があるか」ということです。依存性注入の大きな利点は、提供されているオブジェクトのソースを簡単に変更できることです（したがって、データベースヘルパークラスなどがある場合、依存性注入は、内部の変更可能なデータベースオブジェクトに最適です）。

その情報を収集するために、ここで通常のMySQLの質問をする必要があります（パフォーマンスと保守性）。現実的には、リレーショナルテーブルがある場合、その要点は、結合を使用してクエリを実行し、それらのテーブルをマップできるようにすることです。

他のORMがデータベースからオブジェクトをどのようにハイドレイトするかを見ることができますが、あなたはあなたのアプリケーションを最もよく知っている人です。物事がうまく抽象化されているので、保守性はここで大きな懸念事項である必要があります。

DBが変更された場合は、マッピングオブジェクトを変更するだけでよく、ビジネスロジックが変更された場合は、DBALに触れる必要はありません。

于 2012-12-27T16:51:12.250 に答える