3

私はレールアプリをボトムアップで構築していますが、モデルの関連付けについて少しガイダンスが必要です。

私たちはクライアントを抱えており、複数のプロジェクトに関与しています。クライアントには、プロジェクトに取り組み、ファイルやメモでプロジェクトに貢献するユーザー (従業員) がいます。また、プロジェクトでクライアントと協力します（ファイル、メモを追加します）。プロジェクトには、貢献 (ファイル、メモ) を行う貢献者 (別のクライアントの一部である可能性のあるユーザーまたは下請け業者) がいます。

したがって、モデルに関しては、すべてを適切にキャプチャしていることを確認したいと考えています。これが私が持っているものですが、それがすべて正しいとは確信しておらず、他の協会にも開かれています.

Client
 has_many :projects
 has_many :users

Project
 belongs_to :client
 has_and_belongs_to_many :contributors
 has_and_belongs_to_many :contributions

User
 belongs_to :client
 belongs_to :contributor
 has_many :contributions

Contributor
 has_and_belongs_to_many :projects
 has_one :user
 has_many :contributions

Contribution
 has_and_belongs_to_many :projects
 belongs_to :contributor

貢献は、ファイルとメモのモデルに関連付けられると思います。プロジェクトは「次のステップ」モデルに関連付けられている可能性があります...すべてネストされたリソースとしてだと思います。

ありがとう

4

1 に答える 1

1

関連付けに関するガイドを確認しましたか? これらすべての関連性を明確にするために、モデル ドメインの何らかのペーパー プロトタイプを作成しましたか? これらはプロセスの重要な部分であり、適度に複雑な問題領域では、物事を順調に進めるために重要です。

私はおそらくではなく、関連付けで:contributor関連付けを行いますが、それはおそらく単なる好みです。との不必要な区別であるPhobos98にも同意します。ユーザーアクションをプロジェクトに関連付けるための非常によく考えられたモデルだと思います。Deviseなどのほとんどの認証フレームワークではロールを指定でき、cancanなどではパーミッションをきめ細かく制御できます。Contributionhas_onebelongs_toContributorUserContribution

ネストされたリソースに関する限り、アプリがデータを利用できるようにする方法に関連するだけで、これは実際には別のものです。家を建てるのと同じです。壁を作って中には人や物が入りますが、窓（通路）の数によって、誰が何を見ることができるかが決まります。はい、これらのルートを利用できると便利ですが、データ モデルが適切に配置されていることを確認するために、最初は必須ではありません。

ここにあるモデルを実際に試してみて、それが機能するかどうかを確認しましたか? スキャフォールディングを使用すると、さまざまなことをすばやく試すことができ、Rails ではデータ モデルの変更が簡単になるため、これでもう少し機敏になれない理由はありません。試してみて、何が機能し、何が機能しないかを理解してください。そうすれば、何を変える必要があるかがわかります。

于 2012-12-30T16:50:11.997 に答える