Droga szyn dla wielu typów produktów koszyk zakupów

Question

Projektuję aplikację, która zarządza wynajmem wielu różnych urządzeń. I zastanawiam się, jaki jest najlepszy sposób zaprojektowania modeli dla aplikacji. Mój program ma zarządzać wiele różnych rodzajów sprzętu (z typami danych) na przykład:

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 

Ways myślałem o projekcie:

• Indywidualny wzór dla każdego rodzaju produktu, a następnie polimorficzne skojarzenie w wózku, aby mógł obsłużyć wszystkie typy sprzętu.
• Pojedynczy model produktu, który zawiera pola dla wszystkich typów urządzeń z polem tekstowym, które można sprawdzić, gdy produkt jest używany.
• Model produktu z atrybutem ceny oznacza, że ​​każdy typ produktu rozszerza ten model.

Ale jaki jest najlepszy sposób na szynach do obsługi tych różnych rodzajów produktów?

Answer 1

Dynamic Atrybuty gem powinno pozwolić to zrobić automatycznie:

https://github.com/moiristo/dynamic_attributes

Nie może być lepsze perełki, które robią to, co trzeba, ale jest to pierwszy znalazłem.

Jeśli używasz Postgres jako bazy danych, możesz użyć hstore. Istnieją kamienie do pracy z hstore. Jeśli możesz sobie pozwolić, otrzymaj subskrypcję railscast i obejrzyj screencast o implementacji hstore.

Activerecord-postgres-hstore wydaje się być najlepszym na to.

Answer 2

Inną opcją jest utworzenie tabeli atrybutów produktów i utworzenie każdego typu produktu zamiast interfejsu administratora zamiast kodu niskiego poziomu. W ten sposób nie musiałbyś zmieniać tej aplikacji, aby sprzedawać nowe produkty.

Answer 3

Trzecie podejście jest dość blisko właściwe. Zdecydowanie zechcesz wykreślić wszystkie uniwersalne parametry dla elementów (takich jak identyfikator sklepu i, jak wspomniano, cenę) do modelu podstawowego, który będzie rozszerzał każdy inny element. Następnie, jak wspomniałeś w swoim pierwszym zaproponowanym rozwiązaniu, będziesz miał referencje między pozostałymi klasami elementów, jeśli to konieczne, używając: referencji.

Jeśli chodzi o "typ" i "użycie", najprawdopodobniej najlepiej będzie użyć relacji jeden do jednego z modelem nadrzędnym. Następnie zapisz listę możliwych typów pól dla każdego z modeli (na przykład dla Stand, coś podobnego do possible_uses = "Microphone, Speaker"). Wreszcie, po walidacji po stronie serwera, gdy model jest tworzony, co gwarantuje, że jest poprawnego typu. Możesz także zrobić kilka hacków, które pozwolą ci upewnić się, że Microphone i Speaker są jedynymi możliwymi "zastosowaniami", których twój kod faktycznie używa.

Zupełnie innym, ale czystszym sposobem na zrobienie tego byłoby zrobienie wszystkiego, o czym wspomniałem w pierwszym akapicie, ale kontynuowanie spadku do niższych poziomów. W szczególności, mają Microphone przedłużyć BaseItem, dać Microphone parametry Make i Model, a następnie mają modele InstrumentalMicrophone, VocalMicrophone, and klasę VersatileMicrophone extend the Microphone`. To będzie najczystsze i pozwoli na pełną funkcjonalność.

Answer 4

Chciałbym osobiście pójść z jednym modelem produktu i innym modelem o nazwie ProductAttribute.

W tej tabeli znajduje się kolumna name i kolumna value.

W ten sposób nie jesteś ograniczony przez swój schemat. Produkt ma numer product_attributes, nazwany dynamicznie. Możesz w sekcji administratora tworzyć skróty, więc jeśli utworzysz produkt mikrofonu, automatycznie utworzy on nazwy konkretnych atrybutów w połączonej tabeli. Musisz tylko wprowadzić wartości.

W ten sposób twoja aplikacja jest w stanie sprzedawać wszelkiego rodzaju produty z dowolną ilością atrybutów.Nie musisz ponownie koduwać, gdy za 3 miesiące menedżer będzie chciał dodać inny rodzaj produktu :)

Edycja: Oczywiście masz model ProductType do zarządzania wszystkimi typami produktów, które możesz sprzedać.

Answer 5

Jest to problem, który wcześniej powodował bóle głowy wielu dostawców rozwiązań ERP. Najbardziej eleganckie rozwiązanie, które proponuję Ci w oparciu o to, co zobaczyłem u jednego z takich dostawców, jest takie.

Definiujesz 4 modele: Sprzęt, EquipmentType, Characteristic, Choice.

Istnieje związek między wieloma urządzeniami i charakterystyczny, przechodząc przez Equipment Type. Model charakterystyczny ma atrybut o nazwie "typ_wartości", a także jeden atrybut dla każdego rodzaju wartości (String, Integer, Decimal, Boolean). Wreszcie, istnieje relacja jeden-do-wielu pomiędzy Cechą a Wyborem.

Jest to faktycznie rozwodniona wersja implementacji tego dostawcy, która jest dostosowana do twoich szczególnych wymagań. Rzeczywista implementacja tego dostawcy jest zbudowana na jednym lub dwóch poziomach abstrakcji ponad to, co pokazuję, aby uczynić rozwiązanie bardziej ogólnym. Ale ci ludzie są znani z nadmiernej inżynierii.

HTH.