Изучая django, возник вопрос навеянный опытом разработки на JEE и Spring.
В источниках знаний по django еще не совсем хорошо ориентируюсь. Поэтому может и не смог найти ответ на вопрос.

В основных моментах разработки вроде разобрался. Понятно что есть MVC. Но как быть с так называемым уровнем бизнес логики (business logic layer)? Не понятно мне как она отделяется и реализуется используя django и вообще в его ли это компетенции или просто вынести в модули отдельные и все?

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

Спасибо за внимание к вопросу.  

Нет там такого.  Самый простой способ действительно вынести бизнес-логику в отдельный модуль (пакет) с продуманным API и вызывать из views. По крайней мере такой пакет можно будет покрыть тестами, т.к. в Django вообще с тестированием views дела плохи.

У меня был опыт построения более сложной системы, там все views были заменены на так называемые Actions и ActionsPack, по аналогии с Ruby on Rails. Каждый Action заключал в себе элементарное бизнес-событие, которые объединялись в схожие по смыслу паки. Запускались экшены с четко заданными параметрами, которые по заранее заданным правилам извлекались из POST запроса.

Но я думаю что написать отдельный модуль проще.

Спасибо за ответ, Ch0bits.
Скорее всего так и буду делать дальше.

Может у кого есть еще какие мысли на этот счет?

Это сообщение отредактировал(а) Evgin - 3.9.2010, 09:11

прошу прощения за небольшой троллинг, но почему именно django? После JEE и Spring логичней было бы посмотреть на Grails.

django интересный фреймворк со своим шармом, но после Spring-а и Java будет с ним не совсем комфортно (непривычно).

Сам некоторое время назад выбирал фреймворк для быстрой разработки (имя опыт работы со Spring-ом). Пощупал RoR, Django и Grails. 

Остановился на Grails - все же это тот же Spring (в связке с Hibernate и sitemash), только обернутый в динамический язык Groovy (совместимый с синтаксисом Java, но и имеющий свой "сладкий" синтаксис), scaffolding (как динамический так и статический) и convention over configuration.  
После Spring осваиваешься буквально за пару вечеров. 
Бизнес логика при необходимости выносится а так называемые Service - классы.


п.с  ни в коем случае не хотел сказать что Grails лучше RoR или Django (для того что бы сравнивать я слишком поверхностно знаю последние). Просто после Java и Spring Framework с Grails почти не приходится переучиваться. Плюс, почти все что можно интегрировать со Spring можно интегрировать и с Grails (GWT, Vaadin, Axis2, Spring security, ZK, FreeMarker.......)

Добавлено через 9 минут и 14 секунд
Evgin, 

К слову, есть реализация Spring-а на Python. Насколько вменяема - не знаю, не пробовал.

Это сообщение отредактировал(а) Vasay - 10.9.2010, 01:11

Именно потому что 

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

На мой взгляд как раз такие фреймворки как Django, RoR, Grails позволяют не обращать внимание на многие вещи на которые бы приходилось обращать внимание работая с чем-то типа Spring Framework (и описывать их поведение длинными xml файлами   ).  По крайней мере до тех пор, пока ваши потребности не выходят за рамки предлагаемые фреймворком. 

 

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