web-dev-qa-db-ja.com

データの準備、変換、処理のどの程度がリポジトリレイヤーに属していますか？

PDFファイルに変数を表示するユースケースがあります。しかし、そこに到達するのは簡単ではありませんが、次のようにすることができます：

/*
 * takes product model number, retrieves, processes, formats values
 * returns $variables, ready to plug-in to view with no further processing
 */
$variables = $this->repository->getVariables($model);

/*
 * View runs PDF Library code and displays variables and their values in a table
 */
$this->sendToView($variables);

方法1-リポジトリに変数を変換するすべての作業を行わせる

内部getVariables私はこれらを行います：

  1. データベーステーブル（保存された式）から生データを読み取る
  2. 式エンジンを介してデータを実行します（式を評価します）
  3. 結果の数値データのフォーマット（つまり、小数点以下2桁に丸める）
  4. 金種を追加する（つまり、mmまたはインチ）
  5. データを装飾する（エンジニアリングの許容範囲を置く、または変数の周りに余分な表現を置く）
  6. PDF APIエンジン（ビュー）で使用するためにデータを再グループ化する

すべての作業はgetVariablesで行われ、sendToViewは変数をPDF APIダイレクトとして直接変換します。変換は必要ありません。

方法2-リポジトリを使用して生データのみを取得

反対の極端は、getVariablesが＃1のみを行い、個別のクラスが独自のことを行うことです..

$expressions = $this->repository->getVariables($model);
$solveExpressions = $this->expressionEngine->process($expressions);
$formattedVars = $this->formatter->format($solvedExpressions);
$denominatedData = $this->denom->addMarkers($formattedVars);
$adornedData = $this->adorner->adorn($denominatedData);
$viewReadyData = $this->viewPreparer->prep($adornedData);
$this->sendToView($viewReadyData);

または、上記を混合して一致させ、メソッドをさまざまなクラスに詰め込むこともできます。

私の質問

データの変換、フォーマット、再グループ化、磨き、準備などのうち、どれだけがリポジトリレイヤーに入りますか？

（これにより、リポジトリレイヤーの外で実行する必要のあるデータ操作や、ビューレイヤーで実行するデータ操作を決定するのに役立ちます。つまり、データを簡単に再グループ化して、テーブル）

P.S。何をしようとしているのか（データ操作）

コードに焦点を当てずに、質問のコンテキストで、私がやっていることはこれです-データベースに保存された式から始めます：

a = 5
b = a + 3

それから私は解決された表現で終わります：

a = 5
b = 8

次に、シリーズまたは書式設定と装飾を次のように行います。

8 => 8.00 => 8.00mm => 8.00mm +/-0.01

上記の中にあるような形で滞在

array(
    'a' => '5.00mm +/-0.01',
    'b' => '8.00mm +/-0.01'
);

ビューでは、それを

array(
    0 => array(
        'description' => 'a',
        'value' => '5.00mm +/-0.01'
    ),
    1 => array(
        'description' => 'b',
        'value' => '8.00mm +/-0.01'
    )
);

上記をモダンOOPコードに記述します。

design-patternsphpmvcdatadao
6
Dennis

あなたのコメントに基づいて、いわゆるベストプラクティスやその他の魔法にだまされないように強くお勧めします。主に、ソリューションを次のような方法で実装する方法を選択する必要があります。

  • ソリューションを使用してビジネスの目標を達成するための利害関係者/上司-コードの配置。
  • あなたとあなたのチームは、発生した問題/タスクに誰もがが理解できるようにすばやく対応できるようにする

また、貧血とビジネスオブジェクトについても記述します。私の間違いを証明してください。ただし、一連のメソッド呼び出しの動作やビジネスロジックを理解できません。検証などなしに、一連のデータ変換を行っているようです。なんらかの報告に使われているような気がしますが、本当の意図ははっきりしていません。

私があなたに役立つことができる唯一の有用なことは、あなたのコードを調べ、技術的な領域をキャプチャし、それらを明示的な境界を持つモジュールに分割することです。 懸念の分離 設計原則は、ここで境界を描くのに役立ちます。

  • リポジトリ：データストアのデータの読み取りと書き込みを担当
  • 式エンジン：データの評価
  • フォーマッター：フォーマットと装飾
  • 表示への出力：上記を所定の出力形式に変換/表現

これらの各モジュールは、独自の一連の懸念に責任を持つ必要があります。それぞれに責任があり、何もしないそれぞれのメソッドを持つクラスを作成します。これらの懸念事項をモジュールのセットにカプセル化すると、まとまりが増し、コードのテスト容易性も向上します。

3
kayess