1

サービス、エンティティ、およびリポジトリについて少し混乱しています。また、現在取り組んでいるプロジェクトのために何をどこに置くべきかについても混乱しています。私は何かが欠けていると思い、間違った方法でそれを行っているのではないかと心配しています. 多くの列があり、列は多くの場合、日付、月、年などの他のグループの結果であるため、ドクトリンマッピングテーブル名はレポートに理想的だとは思いません.

プロジェクトの簡単な概要は、Web ベースのレポート (バンドルとして) のコレクションです。

レポートを作成するには、販売ジャーナル バンドルを使用してデータを事前に作成する必要があります。販売ジャーナルは、トランザクション データベースからデータをフェッチし、それを他のさまざまなレポート (カスタム インデックスなどを持つレポート) で実行できるようにテーブルに配置します。データの集計は、それを説明するより良い方法です。データソースには何年も前の数百万の予約データがあるため、ソースに直接基づいてレポートを作成するのは効率的ではなく、販売ジャーナルが登場します。

SalesJournalBundle      - fetches data from source and puts it into a table ready for other reports
WeeklyConversionReportBundle  - exports sales journal into weekly conversion report table has functions for totals for the week, totals for month, etc
OtherReportBundle             - etc

販売ジャーナル

販売仕訳帳を実行し、大きなテーブルから別のテーブルにエクスポートするクラス。

createQuery($parameters);
runQuery($exportTableName);

ウィークリーコンバージョンバンドル

// runs the sales journal and saves to the report.  Entity? Or Service or Repoistory?
runSalesJournalQuery();  

// generates conversion figures and saves the to the table? Entity Or Service or Repoistory?
generateConversions();   


getWeekTotals();         // used when displaying the report..
getMonthTotals($month)   // used when displaying the report..
getTotals()              // used when displaying the report..
etc.

したがって、プロジェクトを開始したとき、すべての関数がエンティティ クラスに属していると想定していましたが、DB アクセスと他のクラスへのアクセスが必要なため、それらが厳密にモデルであるかどうかはわかりませんか? クラス/メソッドをどこに置くべきか混乱しています。どんなフィードバックでも大歓迎です。

4

2 に答える 2

2

  1. ここで Doctrine を使用していると仮定します。

  2. エンティティにクエリを含めることはできません。それらはデータと、おそらくいくつかのビジネス ロジックを保持します。だからあなたのリストからそれらを消してください。

  3. 一般に、リポジトリはクエリを配置する場所です。そこで、runSalesJournalQuery から始めます

  4. generateConversions はおそらくサービスに属しています。結果を永続化する前に、一連の処理を行う必要があると思います。

  5. get スタッフは、リポジトリまたはサービスのいずれかに入る可能性があります。主にクエリである場合は、リポジトリで開始します。主にクエリの結果を処理している場合は、サービスの方が優れている可能性があります。

また、実際には 1 つのリポジトリしか持てないことにも注意してください。複数のサービスに分散すると、コードが管理しやすくなる場合があります。

于 2013-03-07T13:31:51.640 に答える
2

販売仕訳帳を実行して大きなテーブルから別のテーブルにエクスポートすることについて話すとき、私は、小さなことを行うさまざまServicesな人が一緒になってこの大きなタスクを達成することを意味していると思います。

次のような構造が必要だとしましょう。

  • ExportSalesJournalServiceRepository- これには、データベースにアクセスできるクラスへの依存が必要です。SalesJournalRepositoryカスタム クエリを実行するためのカスタム メソッドを使用することもできます。

  • ImportSalesJournalService- これには、他のものと同じ依存関係が必要です。

  • RunSalesJournalService- あなたが意味するものは何でもrunning the sales journal。データベースが必要な場合は、 への依存関係でこれを解決しますRepository。そうでない場合は、何らかのタスクを実行する純粋な昔ながらの PHP クラスです。

独立したオブジェクトを持つことができるように、できる限り物事を分離しようとすることを忘れないでください。これは、保守性、テスト容易性などにも適しています。

もう 1 つ考慮すべきことは、この投稿で述べたように、デフォルトの Symfony 標準アプリケーション構造に従う必要がないということです。これにより、より低結合のアーキテクチャが提供されます。

Entitiesまた、何かを表す純粋でプレーンな PHP クラスでもあります。それらは、ほとんどの場合、ダムオブジェクトであると想定されています。ビジネス固有のコードやデータベースへのアクセスを決して入れないでください。

コンバージョン世代の場合は、カスタムServiceもおそらく同様です。名前の付いたもの、ConversionGenerationServiceまたはそれに近いもの。

クラス名でオブジェクトの意図を提供することを忘れないでください。これは本当に重要です。

レポートに関しては、Service特定の に基づいて、それらを生成するためにおそらく を作成しますRepositories。コンストラクターまたはセッターを使用して、依存関係を明示的に解決することを忘れないでください。

于 2013-03-07T13:40:13.627 に答える