Добрый день,

Вот решил переписать свой первый простой джанго-проект из процедурного php-like cтиля, в красивый ООП-вид. Теперь вот задался вопросом, как идеалогоически правильно организован MVC подход в Django. Насколько я слышал, к примеру, в Рейлс считается что вся механика обработки данных должна храниться в модели, в ПХП я обычно встречался с тем, что модели содержат лишь интерфейс доступа к БД. Собственно вопрос: Где лучше разместить логику обработки данных, к примеру, метод включающий в себя обработку потока данных, и добавление полученной информации в базу? Стоит ли мне создавать отдельный менеджер для этих обработок, или этот процесс можно доверить методу в модели? Снова-таки, статические методы в модели почему-то хотят инициализации класса (т.е. к примеру User.populate() заставить работать у меня не получилось, приходилось сначала делать так user_manager = User(); user.populate()).

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

c уважением,
Михаил

Вопрос слишком общий.
Давайте более конкретно.

http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

regall

Ну, это да, я знаю что такое MVC. Xотелось бы знать как идеалогически правильно все сделать, так как принято в Джанго.

Ferroman

Ну, вот я пишу (вернее написал, но теперь рефакторю) небольшой сервис для себя (для изучения Джанго\Питона). Он обрабатывает данные из твиттера. Каждые н-минут, опрашивает твиттер, получает от него джсон-данные, и после этого я их обрабатываю. Есть, к примеру, таблица с пользователями, в неё записываются юзеры, которые оставляли твиты и информация из их профилей (аватарки, города и т.д.). Твитт каждого юзера добавляется в таблицу твиттов, и плюс к ним сохраняется геоинформация (координаты, и города\страны и т.д.).
Ну и вот к примеру действие обработки данных. У меня была мысль добавить его в качестве метода к таблице твиттов. Обработку гео-данных (т.е. геолокацию, вычисление расстояний и т.д.) - в таблицу мест. Что-то вроде:

Location.objects.get(id=1).distanceTo()
или
Twitts.populate(json_data);
или
User.update_profile(screen_name)

И вот меня интересует, верно ли добавлять такие методы в модель, или необходимо создать отдельные классы представляющие Юзеров, Таблицу Твиттов и так далее, которые будут внутри себя обращаться к моделям?

И вообще, тут похоже, все из Украины :) Здорово.

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

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

Evg

Понятно. Ну что ж, спасибо больше, буду думать :)

Evg
-если логика сильно логически завязана на сущность то ее стоит добавить в модель

тут я имел ввиду что к модели нужно цеплять методом если она использует иформацию только из этой сущности. А если например в логику метода попадает какая либо еще информация о других сущностях через параметры, то быть может стоит оформить метод отдельно ввиде ф-и, все зависит насколько это важная информация в данном контексте.
К примеру есть сущность Article статья и например ее нужно опубликовать, публикует ее User, и вот встает вопрос куда цеплять метод публикации.
Article.publish(user)
User.publish(Article)
или ф-я
publish(Artilce,User)
которую кстати потом можно обернуть двумя методами выше

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

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

Спасибо, так значительно понятней. А не является такое использование процедурного подхода дурным тоном? :)

Если только вы не наровите все засунуть в объект) А объект подразумевает все же некоторое состояние, поэтому не вся логика должна быть ввиде ООП, что-то можно оставить в виде функций. Да и питон это не только для ООП язык.
Да и не забываете что любой метод это на самом деле ф-я у кот 1-й аргумент ссылка на объект и просто вот формально o.meth() = meth(o) … чисто психологическая разница)

Evg
Если только вы не наровите все засунуть в объект) А объект подразумевает все же некоторое состояние, поэтому не вся логика должна быть ввиде ООП, что-то можно оставить в виде функций. Да и питон это не только для ООП язык.
Да и не забываете что любой метод это на самом деле ф-я у кот 1-й аргумент ссылка на объект и просто вот формально o.meth() = meth(o) … чисто психологическая разница)

Ну, это, конечно понятно :) но в данном случае просто интересно как принято это делать в Джанго. Я одно время читал много статей о Руби, и понял, что там принято большенство логики обрабатывать в модели… вот и решил поинтересоваться, как оно у Питонщиков :)