0

CRMに似たレールアプリを構築しようとしています。ユーザーがいて、それぞれの用途には多くの「クライアント」があります。

最初に、ユーザー用とクライアント用のモデルを作成しましたが、単体テストを書いているうちに、これら 2 つがほとんど同じであることに気付きました。

私の質問は、それらを別々にモデル化するという最初の設計上の決定は正しかったですか? または、クライアントが実際にシステムにログインできるようになるとは思いませんが、コードを再利用するより良い方法はありますか?

同様の質問を見てきましたが、それらはすべて異なるユーザー タイプと役割に当てはまります。この場合、クライアントはモデルとしてのみ存在し、実際にユーザーになることはありません。

4

2 に答える 2

1

どの CRM アプリケーションでも、ユーザーとクライアントには類似点と相違点があります。詳細を入れてみましょう

類似点

  • ユーザーとクライアントの両方が、特に個人情報 (名前、連絡先情報など) に関連するさまざまな属性を共有します。
  • 両方 (ほとんど) は、システムに関連する唯一の人物を表します。1 つの明らかな例外は、システム ユーザーです。

違い

  • ユーザーがシステムにアクセスします。これは、認証、識別、許可などのセキュリティの必要性を意味し、これは何らかの検証 (パスワード、証明書など) を意味します。
  • CRM では、クライアントは通常、アカウント、会社、チーム、アカウント マネージャーなどとさまざまな関係を持ちますが、ユーザーは関係ありません。これはモデルによって処理されませんが、一部のフィールドでモデルレベルの検証を行うことを選択する場合があります

したがって、Users と Client を 2 つの異なるモデルに分離するか、それらを結合するか、親からサブクラス化するかは、実際のニーズに基づいた選択です。プロパティを定義する際に、クライアントとユーザーを同じ方法で処理するいくつかのシステム (私の記憶が正しければOpenERPis_system_userなど) があります。個人的には、前述の違いとセキュリティ上の理由から、それらを分離することを選択します。必要性がわからない場合は、それらを分離する方が安全です (DRY'er ではありませんが)。

于 2013-09-22T22:07:28.627 に答える
0

おそらく、ユーザーにタイプを与える必要があります (たとえば、Type モデルを作成し、has_many/belongs_to ActiveRecord 関連付けを作成することによって): ユーザーはクライアントまたは必要なものになることができます。

次に、タイプに応じて、cancan (非常に優れた gem)を使用してユーザー権限を管理できます。

于 2013-09-22T21:06:09.753 に答える