объект symfony2, хранилище, беспорядок службы

Question

Я немного запутался в сервисе, сущности и хранилище, и где я должен помещать то, что для проекта im работает. Я думаю, что им что-то не хватает, и я волнуюсь, что я ошибаюсь. Я не думаю, что имена таблиц сопоставления доктрин идеально подходят для отчетов, потому что есть много столбцов, а столбцы часто являются результатами других групп по дате, месячному году и т. Д.

Краткое упрощение обзора проекта представляет собой набор веб-сайтов отчетов (в виде пакетов).

Для создания отчетов мне необходимо предварительно построить данные с помощью пакета журнала продаж. Журнал продаж извлекает данные из транзакционной базы данных и помещает их в таблицы, готовые к запуску различными другими отчетами, то есть теми, у которых есть пользовательские индексы и т. Д. Агрегирование данных - лучший способ объяснить это. Источник данных имеют миллионы данных бронирований восходящих поэтому его не эффективны строить отчеты непосредственно на источнике Так вот где журнал продажи идет в года.

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 

salesJournal

класса для запуска журнала продаж и экспортировать из большой таблицы в другую таблицу.

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

WeeklyConversionBundle

// 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. 

---

Так что, когда я начал проект, я предположил, что все функции принадлежат классу сущностей .. однако им не уверен, что они строго модели, поскольку они нуждаются Доступ к БД и доступ к другим классам? путают, куда класть классы/методы. Любая обратная связь будет высоко оценена.

Answer 1

Когда вы говорите о работает журнал продаж и экспортировать его из большой таблицы в другую, я думаю, что вы имеете в виду, имеющие разные Services что делать незначительные вещи и вместе решить эту большую задачу.

Допустим, вы бы нужна структура, как это:

• ExportSalesJournalService - Это потребуется зависимость от Repository класса, который имеет доступ к базе данных. Это может быть SalesJournalRepository с некоторыми пользовательскими методами для запуска пользовательских запросов.

• ImportSalesJournalService - Для этого потребуется такая же зависимость, как и другая.

• RunSalesJournalService - Что бы вы ни говорили running the sales journal. Если ему нужна база данных, разрешите это с зависимостью от Repository. Если нет, просто класс PHP, который ставит старую версию, который выполняет определенную задачу.

Помните, что вы можете максимально разделить все, что вы можете, поэтому у вас могут быть независимые объекты. Это хорошо для ремонтопригодности, тестируемости и других вещей.

Еще одна вещь, которую следует учитывать - вам действительно не нужно следовать стандартной структуре приложений Symfony Standard, как я упоминаю в this post. Это даст вам более низкую архитектуру соединения.

Entities также являются чистыми и понятными PHP-классами, которые представляют что-то. Предполагается, что в большинстве распространенных случаев они являются немыми объектами. Никогда, НИКОГДА не добавляйте в них бизнес-код или доступ к базе данных.

Для преобразования преобразования, обычай Service, вероятно, также способ пойти. Что-то названо ConversionGenerationService или что-то рядом с этим.

Упомяните, чтобы указать объект объекта в его названии. Это действительно важно.

Что касается отчетов, я бы, вероятно, создал Service для их создания на основе конкретных Repositories. Не забудьте разрешить разницу зависимостей через конструктор или сеттеры.

Answer 2

1. Предполагая, что вы используете Доктрину здесь.

2. У организаций никогда не должно быть запросов в них. Они содержат данные и, возможно, некоторую бизнес-логику. Так перечеркните их из своего списка.

3. В целом, хранилища являются местом для размещения запросов. Поэтому начните с runSalesJournalQuery

4. generateConversions, вероятно, принадлежит к сервису. Я предполагаю, что он должен выполнить кучу обработки, прежде чем продолжать свои результаты.

5. Получить материал можно в репозиторий или службу. Если это основной запрос, то начните с него в репозитории. Если это в основном обработка результатов запроса, то услуга может быть лучше.

Также имейте в виду, что у вас действительно может быть только один репозиторий. Распространение данных через несколько сервисов может сделать ваш код более управляемым.