Проектирование архитектуры классов модели. Какой из двух вариантов выбрать? Добрый день.
При проектировании архитектуры приложения возник вопрос. Имеется три сущности: Заказчик, Заказ, Исполнитель. Каждый заказ относится только к одному заказчику. Заказ разбивается на составляющие и передается исполнителям. У приложение есть три основные задачи:
1) Создание счетов для заказчиков, включающих заказы.
2) Создание чеков исполнителям, включающих выполненные исполнителями работы.
3) Ведение интерактивной таблицы, отражающей все заказы со всеми подробностями, в том числе и с перечнями выполненных работ и исполнителями в рамках заказа.
Стоимость заказа не зависит от количества и стоимости выполненных работ исполнителями. Заказы и выполненные работы не зависят друг от друга логически, но имеют некоторые общие поля - например дату заказа и др..
В голову приходит два варианта взаимодействия классов:
1. Класс Заказчик хранят в себе сделанные заказы. При этом создание счетов получается очень простой операцией: извлечь из заказчика все его заказы и упаковать в счет.Класс Исполнитель хранит в себе выполненные работы. При этом создание чеков аналогично простое.
Но возникает сложности с ведением интерактивной таблицы (пункт "3)"). Эта таблица формируется из базы данных, а значит для того, чтобы связать заказ с работами исполнителей придется для каждого заказа "потрошить" всех исполнителей в поисках работ выполненных в рамках этого заказа.
2. Класс Заказ - "главный". Он хранит в себе своего заказчика, а также исполнителей и их работы выполненные в ходе заказа. Теперь отображение и изменение этой таблице простое. Но трудности с составлением счетов и чеков, так как чтобы выбрать все заказы определенного заказчика - придется просматривать все заказы. Для выбора всех работ исполнителя для чека - придется просматривать опять же все заказы.
Можно ли как-то объединить эти решения? использовать преимущества обоих без недостатков?
Извиняюсь за много букв, мой первый вопрос тут. Спасибо!
Проектирование архитектуры классов модели. Какой из двух вариантов выбрать? Добрый день.
При проектировании архитектуры приложения возник вопрос. Имеется три сущности: Заказчик, Заказ, Исполнитель. Каждый заказ относится только к одному заказчику. Заказ разбивается на составляющие и передается исполнителям. У приложение есть три основные задачи:
1) Создание счетов для заказчиков, включающих заказы.
2) Создание чеков исполнителям, включающих выполненные исполнителями работы.
3) Ведение интерактивной таблицы, отражающей все заказы со всеми подробностями, в том числе и с перечнями выполненных работ и исполнителями в рамках заказа.
Стоимость заказа не зависит от количества и стоимости выполненных работ исполнителями. Заказы и выполненные работы не зависят друг от друга логически, но имеют некоторые общие поля - например дату заказа и др..
В голову приходит два варианта взаимодействия классов:
1. Класс Заказчик хранят в себе сделанные заказы. При этом создание счетов получается очень простой операцией: извлечь из заказчика все его заказы и упаковать в счет.Класс Исполнитель хранит в себе выполненные работы. При этом создание чеков аналогично простое.
Но возникает сложности с ведением интерактивной таблицы (пункт "3)"). Эта таблица формируется из базы данных, а значит для того, чтобы связать заказ с работами исполнителей придется для каждого заказа "потрошить" всех исполнителей в поисках работ выполненных в рамках этого заказа.
2. Класс Заказ - "главный". Он хранит в себе своего заказчика, а также исполнителей и их работы выполненные в ходе заказа. Теперь отображение и изменение этой таблице простое. Но трудности с составлением счетов и чеков, так как чтобы выбрать все заказы определенного заказчика - придется просматривать все заказы. Для выбора всех работ исполнителя для чека - придется просматривать опять же все заказы.
Можно ли как-то объединить эти решения? использовать преимущества обоих без недостатков?
Извиняюсь за много букв, мой первый вопрос тут. Спасибо!
При проектировании архитектуры приложения возник вопрос. Имеется три сущности: Заказчик, Заказ, Исполнитель. Каждый заказ относится только к одному заказчику. Заказ разбивается на составляющие и передается исполнителям. У приложение есть три основные задачи:
1) Создание счетов для заказчиков, включающих заказы.
2) Создание чеков исполнителям, включающих выполненные исполнителями работы.
3) Ведение интерактивной таблицы, отражающей все заказы со всеми подробностями, в том числе и с перечнями выполненных работ и исполнителями в рамках заказа.
Стоимость заказа не зависит от количества и стоимости выполненных работ исполнителями. Заказы и выполненные работы не зависят друг от друга логически, но имеют некоторые общие поля - например дату заказа и др..
В голову приходит два варианта взаимодействия классов:
1. Класс Заказчик хранят в себе сделанные заказы. При этом создание счетов получается очень простой операцией: извлечь из заказчика все его заказы и упаковать в счет.Класс Исполнитель хранит в себе выполненные работы. При этом создание чеков аналогично простое.
Но возникает сложности с ведением интерактивной таблицы (пункт "3)"). Эта таблица формируется из базы данных, а значит для того, чтобы связать заказ с работами исполнителей придется для каждого заказа "потрошить" всех исполнителей в поисках работ выполненных в рамках этого заказа.
2. Класс Заказ - "главный". Он хранит в себе своего заказчика, а также исполнителей и их работы выполненные в ходе заказа. Теперь отображение и изменение этой таблице простое. Но трудности с составлением счетов и чеков, так как чтобы выбрать все заказы определенного заказчика - придется просматривать все заказы. Для выбора всех работ исполнителя для чека - придется просматривать опять же все заказы.
Можно ли как-то объединить эти решения? использовать преимущества обоих без недостатков?
Извиняюсь за много букв, мой первый вопрос тут. Спасибо!
Похожие вопросы
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Гарантированные бесплатные доработки в течение 1 года
Быстрое выполнение от 2 часов
Проверка работы на плагиат
Поможем написать учебную работу
Здравствуйте! В вашем случае, возможно, стоит рассмотреть использование паттерна проектирования "Хранилище" (Repository).
Вы можете создать классы-репозитории для каждой сущности (Заказчик, Заказ, Исполнитель), которые будут отвечать за доступ к данным этих сущностей из базы данных. Эти репозитории могут содержать методы для получения заказов заказчика, работ исполнителя и других необходимых данных.
Помимо этого, вы можете создать сервисы для работы с заказами и исполнителями. Например, сервис создания счетов и чеков, который будет использовать методы репозиториев для получения необходимых данных и формирования счетов и чеков.
Таким образом, вы сможете сохранить удобство работы с заказами, заказчиками и исполнителями, а также обеспечить удобство работы с интерактивной таблицей, необходимой для отображения всех заказов с деталями.
Другой способ объединить оба варианта - использовать агрегацию и композицию в ваших классах. Например, класс Заказ может содержать ссылки на заказчика и список исполнителей с их работами. Таким образом, вы сможете легко обращаться ко всему необходимому контенту, связанному с заказами, заказчиками и исполнителями.
Надеюсь, это поможет вам в выборе правильного варианта для проектирования архитектуры классов модели. Если у вас возникнут дополнительные вопросы, не стесняйтесь обращаться!