Моделирование пользователей, групп, портфолио и медиа с использованием подхода MVC - PullRequest
Новая
       35

Моделирование пользователей, групп, портфолио и медиа с использованием подхода MVC

0 голосов
/ 21 мая 2009

Я создаю простой дизайн для сайта социальной сети с использованием парадигмы MVC (в CakePHP) для проекта, У меня есть таблица «Пользователи», в которой хранятся все данные о пользователях, у меня есть таблица групп, в которой хранятся все данные о группах, связь между этими двумя моделями имеет и принадлежит многим, затем у меня есть таблица group_portfolios, в которой хранятся все портфели, принадлежащие группа и таблица user_portfolio, в которой хранится вся информация о портфеле, связанная с пользователем. Пользователь может иметь несколько портфелей Группа может иметь несколько портфелей Пользователь может иметь много медиа В группе может быть много медиа

Я разделил функциональность для медиа, связанных с пользователями и группами, Мой вопрос будет,

1) Правильно ли я думаю о моделировании приложения MVC?
2) Так как я разделяю функциональность для пользователей и групп, я получаю две таблицы для всей связанной с ними информации, например, медиа и портфолио. Вызывает ли это какие-либо проблемы, связанные с избыточностью и производительностью, особенно при поиске портфеля и т. Д.? 3) Будет ли возможно масштабирование, когда я захочу добавить больше функций позже?
4) Есть ли лучший способ для моделирования системы?

Спасибо

Ответы [ 3 ]

1 голос
/ 21 мая 2009

Вы можете использовать один носитель и одну таблицу портфолио. Добавьте дополнительное поле, которое сообщает вам, принадлежит ли оно пользователю или группе. Затем не добавляйте в свою модель атрибут $ ownTo, а используйте метод bindModel для динамического присоединения правильной модели.

В качестве альтернативы вы должны также использовать UUID (mysql: varchar 36) вместо целых для ваших идентификаторов. UUID никогда не сталкиваются. Таким образом, вы можете сделать Portfolio и Media принадлежащими к группе и пользователя, используя одно и то же поле. Это работает, потому что никогда не будет пользователя с таким же идентификатором, как у группы, когда вы используете UUID. Пример: 

class Media {
    $belongsTo = array(
        'User' => array('foreignKey' => 'parent_id'),
        'Group' => array('foreignKey' => 'parent_id'),
    );
}

Первое технически более правильно. Последнее легче реализовать, и вам могут не понравиться длинные URL-адреса, создаваемые длинными UUID.

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

См. эту статью в Википедии о вероятности дублирования при использовании UUID. Короткая история: после создания 70000 миллиардов UUID вероятность наличия хотя бы одного дубликата составляет 4 на 10 миллиардов. У вас больше шансов получить удар молнии дважды в один и тот же день: -)

1 голос
/ 21 мая 2009

В дополнение к тому, что Сандер Марешал сказал о GUID, вы можете рассмотреть PolymorphicBehavior для вашей модели Media. Это ускорит ваше приложение, и вам не придется беспокоиться о разрыве отношений в любое время.

О вашем вопросе о дизайне. Мы не знаем ваше приложение и не можем дать подробных ответов. Нет, это ложь: Я не хочу давать потенциально неправильный ответ.

Однако я могу дать вам несколько советов. :) Вы должны сесть и нарисовать свои модельные отношения и подумать, как они будут использоваться в реальной жизни. Затем посмотрите, не пропало ли что-нибудь или, может быть, чего-то слишком много. Оптимизируйте и минимизируйте данные, возвращаемые из вашей базы данных. Решающим понятием здесь является простота . Если это не так просто, как возможно, , это неправильно .

Если вы пройдете половину пути и поймете, что допустили ошибку проектирования - признайте, что допустили ошибку проектирования, и исправьте ее ! Иногда вы не можете все предсказать, и в этом нет ничего постыдного (ну, если вы чему-то научитесь ...).

0 голосов
/ 21 мая 2009

Я использовал RoR и Castle, а не CakePHP, поэтому я буду говорить в общих чертах.

1: То, что вы делали и то, что вы должны продолжать делать, называется «Моделирование домена» - MVC отлично подходит для этого, поскольку ваши модели становятся представлениями объектов в вашей модели домена

2: Вы можете изменить модель портфолио и мультимедиа, чтобы вместо ссылки на идентификатор своего родителя у вас были «ObjectId» и «ObjectType» - ObjectId - это идентификатор родителя, а ObjectType - это тип. Вы не сможете автоматически связать отношения, но вместо этого сможете сделать это с помощью пользовательского кода, поэтому, чтобы получить все медиафайлы для пользователя, он становится 

select * from Media where ObjectId = [userid] and ObjectType = 'User'

вместо 

select * from UserMedia where UserId = [userid]

3: да, это масштабируемый дизайн не забудьте вставить как можно больше работы по конкретным моделям в сами модели (или репозитории), чтобы она «просто работала»

4: Возможно, но вы никогда не получите «идеальную» систему. MVC великолепен, и ваш дизайн кажется надежным для простой социальной сети. Вы без сомнения добавите такие вещи, как посты / комментарии и т. Д.

...