2

これが以前に議論され、検索して検索したが、有用なものが見つからなかった場合は、お詫びします:)

しかし、ここに行きます。現在、ウェブアプリの一部を書き直しているところです。私たちのアプリはかなり古いため、プログラミング、規約、URLに対するカウボーイ風のアプローチに悩まされています。

私たちが探しているのは、ビューとURLを設計するためのシンプルでクリーンな方法であり、将来的に両方を簡単に維持できるようになります。

問題は; 現在のところ、メインサイトのurls.pyファイルは大きな混乱の1つです。1つのシンのみを実行する一意のビューを指す多くのURL。元。list_books /、edit_book /など、特定の形式などに関しては、list_books_json/のようなものがあります。

(これらは実際のURLではありませんが、実際のURLの方がはるかに悪いため、ポイントを証明するために使用されています)

私たちが今やりたいのは、それを少しクリーンアップすることです。そして、私たちはそれを回避するための最良の方法は何であるか疑問に思っていますか?

これまでに考えたこと(このテーマについて多くのことを読んだ後):

次のパターンに従ってURLを設計することを考えました:domain / object / action /

したがって、アプリで本を変更するためのアプリの「スタッフ」サイトのURLは次のようになります。スタッフ/本-すべての本を表示する(GET)スタッフ/本/ ID-1つの本を表示する(GET)スタッフ/本/新規-新しい本を作成する(POST)スタッフ/本/ ID /編集-特定の本を編集する(POST)スタッフ/本/ ID /削除-特定の本を削除する(POST)

その場合、サイトの「スタッフ」部分を介して本を処理するときにこれらすべてのアクションを処理するために、views.staff_books()という1つのビューのみを持つことが考えられました。これにより、staff_books()はIDまたは特定の「アクション」(編集、新規、削除など)をチェックします。

結果は少なくなりますが、スタッフ/本のすべての側面を処理する必要があるビューがはるかに大きくなります。現在、1つのことだけを処理する小さなビューがたくさんあります。

これは理にかなっていますか、潜在的な問題を見ることができますか?どうやってやるの?

私たちが迷子になっていると思う場所の1つは、フォーマットに関するものです。あなたは元をどこに置きますか?jsonで応答を返すためのリクエスト?「staff/books.json」や「staff/books / ID.json」などを考えて、すべてのjsonロジックを同じ「staff_books()」ビューに保持します。

基本的には以上です。質問が少し「ふわふわ」であると申し訳ありません...基本的に、URLとビューを構造化する方法についていくつかの例または優れた設計アドバイスが必要です。

敬具

ピート

4

1 に答える 1

1

問題の拡張(および解決策)として、戦略パターンを使用することをお勧めします。あなたはすでに構造を持っていて、それが実行されることになっている「方法」だけが異なるので、このパターンはあなたの問題に完全に適合します。それが意味するのは次のとおりです。

  1. URLベースの機能(編集、新規、削除など)として指定された関数を使用して、アプリケーションへのエントリポイントとなるビューを作成します。つまり、url.pyがそこからどこに行くかを決定します。
  2. ドメインなどに基づいて自分の作業を行うクラスを作成します。今のところ、それらをBook、Calendarなどと呼びましょう。
  3. 編集、新規、削除など、これらのクラスの機能を実装します。
  4. 次に、ビューで、インスタンス化するクラスを決定し、対応する関数を呼び出します。たとえば、View.edit()でdomain.edit()を呼び出します。

私はそれがそれをするべきだと思います^^それが役立つことを願っています:D

于 2013-05-17T12:17:22.797 に答える