Где вычисленные значения принадлежат шаблону MVC?

Question

В приложении, которое я создаю, у меня есть понятие пользователя.

В приложении пользователи имеют страницы профиля.

Это довольно просто. Они в основном похожи на / profile? Id = 3 или где-то еще, где 3 - это идентификатор пользователя, профиль которого я хочу видеть.

Имеет ли смысл добавлять метод url_for_profile в модель User, или мне следует просмотреть URL-адреса профиля пользователя или сделать что-то еще полностью?

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

Спасибо за совет!

Answer 1

Это зависит от того, какой слой решает, что такое URL.

Если URL-адреса по какой-то причине определены слоем модели (клиент-серверное приложение, которому необходимо время от времени ссылаться на веб-сайт), то объекты модели должны иметь методы для получения URL профиля.

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

Answer 2

Я не вижу в вашем требовании ничего, что говорит о том, что пользователь должен знать, что такое URL. Если вы реализуете этот метод, вы подразумеваете, что вы можете получить такие вещи, как Order.url_for_order или Cart.url_for_cart. Если вы хотите изменить способ указания URL-адресов, вам придется изменить все классы. Желательно, чтобы все объекты в вашей системе имели идентификатор и вспомогательный класс View, у которого есть такой метод, как: URLHelper.url_for_object (MyObject)

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

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

Answer 3

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

Несмотря на то, что вы можете создать другое представление, но неявная адресация может создать проблемы при более длительной работе, так как проект и база данных растут, становится слишком сложно понимать и управлять тем, что и где происходит. Так что даже если вы создаете новое представление, у вас все равно должен быть url_for_profile, который можно использовать для кластеризации. Если вы заметили, каждая ссылка на Microsoft имеет такой формат ... go.microsoft.com/linkID=XXXXXXX,