concepção do projeto layout / FS para grandes projectos de Django

votos
40

Qual é a melhor maneira de layout de um grande projeto de Django? Os tutoriais fornecem instruções simples para a criação de aplicativos, modelos e pontos de vista, mas há menos informação sobre como aplicativos e projetos devem ser discriminados, quanto a partilha é permitido / necessário entre aplicações em um projeto típico (obviamente que depende em grande medida do projeto) e como / onde modelos gerais devem ser mantidos.

Alguém tem exemplos, sugestões e explicações sobre o porquê de um determinado layout do projeto é melhor do que outro? Estou particularmente interessado na incorporação de um grande número de testes de unidade (2-5x o tamanho da base de código real) e externalização corda / templates.

Publicado 04/09/2008 em 17:36
fonte usuário
Em outras línguas...                            


6 respostas

votos
17

As principais diretrizes são semelhantes a qualquer outro projeto de código grande. Apps deve abordar uma única responsabilidade, claramente definida. O nome "aplicação" é um equívoco; Aplicações Django deve ser pensado mais como componentes reutilizáveis ​​que podem ser conectados em conjunto para criar uma aplicação real. Testes para cada aplicativo deve ser contido dentro desse aplicativo. Apps deve ser dissociado do outro, tanto quanto possível, mas é evidente que haverá dependências, de modo que o objetivo deve ser manter o gráfico de dependência tão simples e saudável possível.

Eu prefiro manter todos os modelos para um projeto em um único diretório modelos de todo o projeto, com um subdiretório para cada aplicativo (usando um subdiretório modelo para cada aplicativo é um muito forte convenção em Django, uma vez que evita colisões de nomes modelo entre aplicativos) . A razão para um único diretório modelos de todo o projeto é que modelos, árvores de herança de modelo e nomes de blocos pode ser bastante projeto-específica, por isso é difícil para fornecer modelos de aplicativos "padrão" que podem ligar para qualquer projeto. Houve algumas tentativas para resolver sobre convenções de nomenclatura padrão para os modelos de todo o site de base e os blocos que definem, mas eu não vi um padrão emergir ainda (a forma como eles fazem as coisas em cima da Pinax é provavelmente o mais próximo que temos de uma padrão).

Re "externalização cadeia", se você quer dizer i18n e l10n, Django tem um forte apoio para que e padrão lugares onde ele coloca os arquivos .po - verificar os docs .

Respondeu 25/09/2008 em 20:30
fonte usuário

votos
9

Eu achei o layout do Zachary bastante útil Blog »Convenções Django projeto de Zachary Voase, Revisited.

Respondeu 22/04/2010 em 02:17
fonte usuário

votos
6

Esta página faz um bom trabalho de abordar algumas das minhas perguntas: http://www.b-list.org/weblog/2006/sep/10/django-tips-laying-out-application/

Especificamente:

  1. Para definir tags de modelos personalizados ou filtros, você deve criar um subdiretório no diretório chamado templatetags do aplicativo, e deve conter um __init__.py arquivo chamado para que ele possa ser importado como um módulo Python.
  2. Para definir testes de unidade que irá automaticamente serem notadas por framework de testes do Django, colocá-los em um módulo chamado testes (que pode ser um tests.py arquivo chamado ou um diretório chamado testes). O framework de testes também vai encontrar nenhum doctests nesse módulo, mas o lugar preferido para aqueles que, é claro, as docstrings das classes ou funções que eles estão destinados a testar.
  3. Para fornecer SQL personalizada que será executado imediatamente após a sua aplicação é instalada, criar um sub-diretório chamado sql dentro do diretório do aplicativo; os nomes de arquivo deve ser o mesmo que os nomes dos modelos cujas tabelas eles operam em; Por exemplo, se você tiver um aplicativo chamado weblog contendo um modelo chamado de entrada, em seguida, o arquivo sql / entry.sql dentro do diretório do aplicativo pode ser usado para modificar ou inserir dados na tabela de entradas, logo que ele foi criado.

A nota sobre tests.py e testes (diretório) também é válido para os modelos, o que ajuda a resolver o problema de ter maneira de muitos testes (ou modelos) para um arquivo.

Eu ainda gostaria de ver alguns exemplos / sugestões para app / projeto quebrar, e sites Django grandes que funcionam bem.

Respondeu 04/09/2008 em 17:44
fonte usuário

votos
3

O projeto Pinax é construído em torno da idéia de pequenas aplicações reutilizáveis, que são facilmente reunidas em um projeto. Eles usaram o projeto Nuvem 27 como um projeto de demonstração.

O projeto Django que estou trabalhando (chamado Basie. É pré-0.1, por isso ainda nenhuma ligação.) Está tentando seguir o modelo Pinax, e até agora está funcionando muito bem.

Respondeu 31/10/2008 em 01:22
fonte usuário

votos
1

Eu realmente gosto de Randall Degges' post sobre este assunto. Ele deixa de fora informações sobre como colar as configurações de arquivos juntos, mas eu vou ter um post em que eu vou ser capaz de ligar, mas por agora qualquer um pode conferir o meu repo onde eu incluir alguma direção no readme.

Respondeu 21/07/2012 em 13:40
fonte usuário

votos
1

Meu layout atual decorre de me querer ter um teste de versão dos meus sites. Isto significa ter dois projetos para cada site, pois eles precisam de configurações diferentes, e me obriga a mover todos os aplicativos fora dos projetos.

Eu criei duas pastas: $ APP_ROOT / devel e US $ APP_ROOT / prod. Estes contêm todos os apps. Usando o controle de origem (no meu caso git) Eu tenho os aplicativos em devel na revisão HEAD, enquanto as aplicações em prod estão bloqueados para a tag PROD. Os modelos também têm a sua própria pasta com o mesmo layout das apps.

Agora eu sou capaz de fazer todo o meu desenvolvimento na pasta devel-apps e o gabarito de pasta correspondente. Quando eu tenho algo que eu estou feliz com, eu marcar essa revisão e atualização prod.

Respondeu 09/01/2009 em 11:35
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more