applicationの単位
Shuji Watanabe
今、Django本を読みながらWebアプリケーションを作成しているのですが、
applicationの分割単位に関して判断ができなかった為、ご教授願えればと思います。
例えば、ショッピングサイトの管理ツールを作成するとした場合、
・カテゴリ管理機能
・商品管理機能
・注文管理機能
・ユーザ管理機能
のような感じで大まかな機能が抽出できると思います。
djangoのadmin機能を使わない場合、それぞれの機能で１つのapplicationとして配置する事は妥当でしょうか？
また、admin機能を使う場合だとどうでしょう？
状況にもよるかとは思いますが、どのような基準でapplicationを分けるのが一般的なのでしょう？
以上、よろしくお願いします。
tsuyuki makoto
再利用可能なものはアプリケーションを分けると良いと思います。
逆に言えば、再利用できるほど汎用的に作れない物については
同じアプリケーション内に入れてしまっていいと思います。
例に出されているショッピングサイトの管理機能については、
私はすべての機能を一つのアプリケーションとして構築して
しまうと思います。
＃ユーザ機能の基本部分はdjango.contrib.authを使うと想定した場合
もちろん、いろいろな意見があると思いますが…
2008/07/26 20:45 Shuji Watanabe <shuj...@gmail.com>:
Shuji Watanabe
> 再利用可能なものはアプリケーションを分けると良いと思います。
> 逆に言えば、再利用できるほど汎用的に作れない物については
> 同じアプリケーション内に入れてしまっていいと思います。
なるほど。
しかし、そのような分け方だと、プロジェクトとアプリケーションの区別が解らなくなって来ました。
先ほどのオンラインショップの例だと、お店の名前でプロジェクトを作り、その下に単一のアプリケーションを配置する、という感覚なのでしょうか？
例えば、
project: shop98
application_name: onlinestore
ちなみにこのように配置した場合、viewsとmodelsの肥大化が怖いです。
これも一般的にこうするという方法があれば教えていただければと思います。
Atsushi Senoma
DjangoのアプリでSatchmo(http://satchmoproject.com/)というのがあります。
こちらは、機能ごとに分割されており、newforms-adminに対応しています。
参考になると思うので一度見てはいかがでしょうか。
2008/07/26 23:38 Shuji Watanabe <shuj...@gmail.com>:
Yasushi Masuda
アプリケーションの分割単位はあまり明確なガイドライン
がなくて、意見の分かれるところです。ただ、私自身はか
なりバラバラにアプリケーションを分割します。分割する
時に考えるのは、ユーザがデータを扱うときに、入力フォー
ムなどで一度に編集するデータの最小範囲でモデルやフォー
ムやテンプレートがまとまるはずなので、そこで区切る、
ということです。
で、私なら、わたなべさんの抽出した機能、
> ・カテゴリ管理機能
> ・商品管理機能
> ・注文管理機能
> ・ユーザ管理機能
を全部別々のアプリケーションにします。
プロジェクトとアプリケーションの関係は、チュートリアル
が元凶でよく誤解されています。アプリケーションをプロ
ジェクトに入れるのは、実は王道ではありません。チュート
リアルでそうしているのは、そうした方が書きやすいからな
のと、小さなプロジェクトで、アプリケーションの再利用
も検討していないから手を抜いているだけです。本来、
プロジェクトは、アプリケーションを組み合わせてサイトを
作るためだけに使います。普通は settings.py とルート
URLConf をいじるだけで、後は手を加えません。
アプリケーションをすでに作っている場合は、PYTHONPATH
上のどこかに置いて、 INSTALLED_APPS にも 'appname'
としか書きません。
複数のアプリケーションをまとめてキットにしたければ、
(一つのディレクトリに入れて__init__.pyを入れて)パッケー
ジにし、パッケージをインストールして(PYTHONPATH上に置い
て) INSTALLED_APPS に 'packagename.appname' と書いて
使います。なので、上のショッピングサイトの例なら、
私は
shopping/ (パッケージ)
shopping/category/ (カテゴリ管理)
shopping/goods/ (商品管理)
...
のように作り、別にプロジェクトを作成して、その中で
'shopping.category', ... を INSTALLED_APPS に組み込み
ます。
---
Yasushi Masuda
http://ymasuda.jp/
Shuji Watanabe さんは書きました:
Shuji Watanabe
様々な意見ありがとうございます。
私自身は、Javaを中心にやってきたもので、細かく分割するほうが好みですね。
たとえばJSFのフレームワークであるTeedaなどを使った場合でも、
サブアプリケーションとい形で大きな単位でのユースケース毎に分けます。
ところで、実はこのような質問を投げた理由は別にあったりします。
本当は細かい単位でアプリケーションを切っていくような実装にしようと
shop.category
shop.item
のような構成を作りました。
最初にcategoryのmodelsを作成し、CRUDを試し・・・とまでは順調だったのですが、
itemのmodelで、外部参照（FKとしてitem_id）を作ろうとしたところ、MySQLでFKが晴れないという現象でした（Djangoは0.96）
ですが、itemの下にあるitem_detail （1:n）はまったく同じ記述をして、FKが晴れるのに・・・、と。
ここはあくまで推測だったのですが、アプリケーションは独立して動かす前提なのでは？という事です。
そう考えると、アプリケーションを跨いだcategoryへのFKは張られずに、item_detailと生成されるテーブルに違いがあることが納得できます。
（このあたりで、そもそも分割単位は細かくてよいのだろうか？と疑問を持ち投稿しました）
こうなってくるともう１つ質問お願いします。
> shopping/ (パッケージ)
> shopping/category/ (カテゴリ管理)
> shopping/goods/ (商品管理)
> ...
>
> のように作り、別にプロジェクトを作成して、その中で
> 'shopping.category', ... を INSTALLED_APPS に組み込み
> ます。
この説明は非常にしっくり来ました、ありがとうございます。
その中で気になるのはmodelsですが、これはshoppingパッケージにあるのはアリでしょうか？
各アプリケーション間での依存関係は低くしたい、と考えるとshopping/commonのようなアプリケーションを作成するか、shopping以下に配置するという考えにいたってしまいます。
Yasushi Masuda
もう0.96を使わなくなって久しいのですが、他のアプリケーションの
モデルに外部キーが張れないというのは経験したことがありません。
張ろうとすると、どういう現象が起きるのでしょうか？
「今のところ」、 shopping 直下に models.py を置くのは可能で、
shopping 自体がアプリケーションとして扱われます（INSTALLED_APPS
に 'shopping' を入れて使います。が、私自身は、アプリケーションの
中にアプリケーションが入っていると気持ち悪いので、
shopping.common を作ります。
---
Yasushi Masuda
http://ymasuda.jp/
Shuji Watanabe さんは書きました:
Shuji Watanabe
validate, syncdb 共にエラーとはなりません。
ところで、1.0の方で試しても見たんですが、こちらでは
他のアプリケーションにあるモデルでもForing Keyが張られました。
最終的には1.0系で作っていくことにしたので、過去の仕様なのかな？という状態です。
テンプレートにGenshiを使ってみたところ、マルチバイト系の問題で0.96では動かなかったんでorz
（0.96でもWindowsでは動くんですけど、Linux上ではGenshiで展開するときにDecodeErrorになる）
違いはこんな感じです
1.0
http://f.hatena.ne.jp/shuji_w6e/20080730223545
0.96
http://f.hatena.ne.jp/shuji_w6e/20080730130547
================================
Shuji Watanabe
http://www.deathmarch.jp/
http://d.hatena.ne.jp/shuji_w6e/
2008/07/30 9:48 Yasushi Masuda <yma...@ethercube.com>: