Работая с Catalyst, обнаружил, что очень многие вещи (в том числе и те, что к модели не отноятся) удобно реализовывать через наследование класса строки таблицы DBIx.

Например есть таблица, содержащая статьи, публикуемые на сайте. Удобно добавить к классу строки таблицы методы, возращающие url статьи и url страници админки для редактирования статьи . Но это, если я правильно понимаю MVC, это задача для контроллера.

Или есть таблица с пользователями, у которых есть логин, имя и фамлия, а на имя пользователя часто выводится в формате "username (Имя Фамилия)", имя и фамилия не обязательны.
Т. е.

Удобнее один раз добавить метод обьекту строки таблицы. Эта задача для view.


Но добавляя методы одному классу строки таблицы, получим смешение model, view, controller в одном файле. Как быть? 


Это сообщение отредактировал(а) Logo - 14.10.2010, 18:18

отдавайте во View не объект типа User, который представляет строку таблицы, а заводите промежуточный класс ну например DisplayedUser и отдавайте его экземпляр.

в Model


а во View:

Собственно, в том и загвоздка, что код помещается в model. А представление данных должно быть во view.

Logo, представление - очень растянутая вещь.. 
Нет смысла строго придерживаться MVC, если при этом страдает простота и понятность.
У вас есть данные - класс Человек. Данные тоже могут обладать методами, возможно отличными от get/set.
Например, у вас хранится полное имя - Иван Иваны Анонимкин, а вы хотите получать сокращенное - И.И.Анонимкин,
эта логика настролько сильно привязана к данным, что ее правильно помещать в модель.

В вашем случае 

так же можно поместить в модель. Главное, что бы он не был в перемешку с html. 

А вот в случае с URL на страничку статьи - не нужно помещать ее в модель. 
URL вообще имеют свойство меняться. Их желательно никуда не харкодить.

Ну, до html там не далеко, возможен вариант username (Фамлия Имя).

Url-ы тоже просто в схему записывать? Ведь это удобно - генерация урла только в одном месте.

да, только этим местом не должна быть модель.

Посмотрите Django - там вообще предполагается, что приложение не должно знать полную структуру URLов,
т.к. маппинг URLов на обработчики осущесвтляется программистом в момент установки приложения.
Просто представьте себе, что кто-то захочет использовать ваше приложение как часть своего сайта.
Что потом делать с вашими URLами?

Есть тип данных/класс, К примеру App::Schema::Article. У статьи должен быть генератор урла, который должен генерировать url самой статьи и url статьи в админке. Тоесть, фактически, метод в ООП. Я и добаляю генерацию урла как методы App::Schema::Article. Но т. к. эти методы я определяю там же, где и чисто "модельные" методы, получается смешение.

Добавлено через 9 минут и 39 секунд
Делать url hardcode, или нет, другой вопрос. URL можно делать через uri for action.