2012-01-20 1 views
8

У меня есть вопрос о MVC. В частности, о моделях. Предположим, что у меня есть таблица категорий в моей базе данных. Теперь я хотел бы получить результаты как для отдельной категории для подробного просмотра, так и для нескольких категорий для листинга. Также мне может потребоваться запросить несколько категорий для разных целей.Несколько моделей против одной модели

Теперь вопрос в том, Имеет ли смысл иметь две отдельные модели. Как модель категории для операций над одной категорией и категориями моделей операций по нескольким категориям.

Мое мышление заключается в том, что при использовании модели category мне не нужны дополнительные данные для нескольких категорий. Поэтому разделение их имеет смысл для меня. Но я не уверен.

Любые идеи?

+0

«Теперь я хотел бы вопросы как одну категорию для деталей» не имеет смысла. Вы можете исправить, пожалуйста? –

ответ

2

Это зависит от того, вам нужно сохранить различные данные для одной категории и для нескольких категорий?

Если так, ваше предложение имеет смысл, поскольку в противном случае у вас были бы избыточные поля в вашей модели. Я бы посоветовал сделать четкое различие между обеими моделями (поэтому не Category и Categories, но, например, SingleCategory и MultipleCategories).

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

В последнем случае вы можете использовать абстрактный суперкласс Category, а затем определить два дочерних элемента: один, который содержит операции для отдельных категорий, и один, который содержит операции для нескольких категорий.

5

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

Поэтому я советую использовать одну модель и разработать методы для получения точных данных, которые вам нужны.

Имея две модели для одного источника данных только усложняет материал ...

+2

Я не согласен с этим, я думаю, что вопрос был упущен. Во-первых, это выбор дизайна, независимо от того, содержит ли ваша модель логику запроса базы данных. Некоторые из них предпочитают разделять логику с объектами buiness (модель данных) и адаптерами данных/услугами, которые возвращают списки или отдельные бизнес-объекты. В любом случае дело в том, что второй предлагаемый объект не дублирует ничего, он просто повторно использует существующую модель, сохраняя коллекцию моделей отдельных экземпляров и некоторые дополнительные свойства для информации об этой коллекции. Это хорошая идея imo –

1

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

В MVC модель представляет собой сбор данных - это могут быть отдельные или несколько элементов. Если конкретная модель представляет только один элемент, она по-прежнему является частью сбора данных.

Зачем вам интересно использовать две отдельные модели?

0

Это просто зависит от ВАС!

Вы программист, который вам подходит.

Однако, чтобы добавить мои рассуждения:

Один класс модель будет лучше с точки зрения читаемости и ремонтопригодность!

например.

class get_fruits 
{ 

function all_fruit(){} 

function one_fruit(){} 
} 

Это было бы очень легко для другого программиста читает код, чтобы понять

например

$get = new get_fruit(); 
$europeanfruits = $get->all_fruits("European"); 
$apple = $get->one_fruit ("Apple"); 

Надеюсь, это поможет!

Помните, что правильное или неправильное решение отсутствует, так как оно работает на вас!

0

На мой взгляд, списки, массивы, коллекции и т. Д., Которые предоставляются языком, который вы используете, являются допустимым выбором для коллекций моделей, и вы не должны создавать дополнительную модель, которая просто обертывает эту коллекцию, поскольку она действительно ничего не достигает вообще. Вы можете рассмотреть возможность объединения коллекции в модель, если вы хотите связать некоторый интерфейс с коллекцией.

Если вам нужна дополнительная информация о коллекции, вы должны обернуть ее в другую модель.

Я также не согласен с тем, что у вас не должно быть нескольких моделей, потому что данные поступают из одного источника данных. На самом деле, я считаю, что вы не должны размещать логику базы данных в самой модели, а использовать отдельную службу, которая возвращает бизнес-объекты. Этот уровень инкапсуляции позволяет вам манипулировать моделями высокого уровня (или бизнес-объектами) на уровне приложений при развязывании логики доступа к данным с этих объектов. Если вам нужно перейти и заменить базу данных чем-то другим, вам нужно только заменить логику доступа к данным и интерфейс, который создает модели.

1

Что мы сделали в наших собственных MVC и ORM, так это то, что мы создали оболочку для операций с несколькими экземплярами модели. Это ResultSet. Затем набор результатов может выполнять операции, например, для массива категорий.

Для справки: https://github.com/Tuxion/tuxion.cms

 Смежные вопросы

  • Нет связанных вопросов^_^