9

さまざまな機器のレンタルを管理するアプリケーションを設計しています。そして、アプリケーションのモデルを設計するための最良の方法は何でしょうか。私のソフトウェアは、たとえば次のようなさまざまな種類の機器（データ型を含む）を管理する必要があります。

Speaker
  Make - String
  Model - String      
  Wattage - Integer
  Price - Decimal

Light
  Make - String
  Model - String      
  Wattage - Integer
  Price - Decimal

Microphone
  Make - String
  Model - String
  Use - Choice of: Instrumental, Vocal, Versatile
  Price - Decimal

Cable
  Length - Decimal
  Connector 1 - String
  Connector 2 - String
  Price - Decimal

Stand
  Type - Choice of: Microphone, Speaker
  Height - Decimal
  Boom - Boolean
  Price - Decimal

私がデザインについて考えた方法：

  • 製品のタイプごとに個別のモデルを作成し、カート内の多態的な関連付けにより、すべてのタイプの機器を処理できるようにします。
  • 製品が使用されるたびにチェックできるタイプフィールドを備えた、すべてのタイプの機器のフィールドを持つ単一の製品モデル。
  • 価格属性を持つ製品モデルでは、すべてのタイプの製品がそのモデルを拡張します。

しかし、これらのさまざまなタイプの製品を処理するためのレールの最良の方法は何ですか？

4

5 に答える 5

4

Dynamic Attributes gem を使用すると、これを自動的に行うことができます。

https://github.com/moiristo/dynamic_attributes

必要なことを行うより良い宝石があるかもしれませんが、これは私が最初に見つけたものです.

Postgres をデータベースとして使用している場合は、hstoreを使用できます。hstore で動作する gem があります。余裕がある場合は、railscast のサブスクリプションを取得し、hstore の実装に関するスクリーンキャストをご覧ください。

Activerecord-postgres-hstoreは、このための宝石のようです。

于 2012-07-28T16:36:18.573 に答える
2

個人的には、1 つのモデル Product と ProductAttribute という別のモデルを使用します。

このテーブルには、name列と列がありvalueます。

このようにして、スキーマに制限されません。product_attributes製品には動的に名前が付けられたnがあります。管理セクションでショートカットを作成できるため、マイク製品を作成すると、リンクされたテーブルに特定の属性名が自動的に作成されます。値を入力するだけです。

このようにして、アプリケーションは、任意の量の属性を持つあらゆる種類の製品を完全に販売できます。マネージャーが 3 か月後に別の種類の製品を追加したい場合、再度コーディングする必要はありません :)

編集：もちろん、ProductType販売できるさまざまな製品タイプをすべて管理するためのモデルがあります。

于 2012-07-28T12:23:53.693 に答える
1

これは、ERP ソリューションの多くのベンダーにとって以前から頭の痛い問題でした。私がそのようなベンダーで見たものに基づいて提案する最も洗練されたソリューションはこれです。

Equipment、EquipmentType、Characteristic、Choice の 4 つのモデルを定義します。

EquipmentType を介して、Equipment と Characteristic の間には多対多の関係があります。Characteristic モデルには、「value_type」と呼ばれる属性と、値の型 (String、Integer、Decimal、Boolean) ごとに 1 つの属性があります。最後に、Characteristic と Choice の間には 1 対多の関係があります。

これは実際には、特定の要件に適した、そのベンダーの実装の簡素化されたバージョンです。そのベンダーの実際の実装は、ソリューションをより一般的なものにするために、私が示しているものよりも 1 つまたは 2 つの抽象レベルで実際に構築されています。しかし、それらの人々は物事を過剰に設計することでよく知られています。

HTH。

于 2012-08-03T09:59:31.203 に答える
1

もう 1 つのオプションは、製品属性テーブルを作成し、各製品タイプを低レベル コードではなく管理インターフェイス上で構築することです。そうすれば、新製品を販売するためにアプリケーションを変更する必要がなくなります。

于 2012-06-16T18:41:38.933 に答える
0

3 番目のアプローチは、正しいアプローチにかなり近いものです。他のすべてのアイテムが拡張する基本モデルに、アイテムのすべての普遍的なパラメーター (ストア ID や、前述のように、価格など) を抽象化する必要があります。次に、最初の提案されたソリューションで述べたように、:references を使用して、必要に応じて残りのアイテム クラス間の参照を作成します。

「タイプ」と「用途」に関しては、おそらく親モデルとの 1 対 1 の関係を使用するのが最善でしょう。次に、モデルごとに可能なフィールド タイプのリストを保存します (たとえば、 のStandようなものpossible_uses = "Microphone, Speaker")。最後に、モデルがインスタンス化されたときにサーバー側の検証を行い、モデルが有効な型であることを確認します。また、コードが実際に使用する可能性のある「用途」が と の 2 つだけであることMicrophoneを確認できるハックを行うこともできます。Speaker

これを行うための完全に異なる、しかしよりクリーンな方法は、最初の段落で述べたすべてのことを行い、継承を下位レベルまで継続することです。具体的には、MicrophoneextendBaseItemを用意Microphoneし、パラメータMakeとModelパラメータを指定してから、models InstrumentalMicrophone、VocalMicrophone, andVersatileMicrophone extend theMicrophone` クラスを用意します。これは最もクリーンで、すべての機能を使用できます。

于 2012-07-27T22:02:12.503 に答える