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