---

Hallo,

Man hat ja im BMIDE die Möglichkeit ein "abstractes" Item zu erstellen, welches als übergeordnetes Item für weitere ItemTypen dient.

Bei uns ist das auch so der Fall, aber ich bin mir nicht sicher ob dieser Ansatz gescheit ist. So lange alle untergeordneten Items die gleichen Properties haben sollen leuchtet mir das ja noch ein, aber ob das tatsächlich so bleibt ist die Frage.

Wie ist eure Meinung dazu? Nutzt ihr die Möglichkeit eines abstracten Items oder erstellt ihr für jeden Item Typ ein eigenständiges?

Vielen Dank!

Grüße,

Thomas

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

>>So lange alle untergeordneten Items die gleichen Properties haben sollen leuchtet mir das ja noch ein, aber ob das tatsächlich so bleibt ist die Frage.

Die Sinnhaftigkeit eines übergeordneten Items hängt natürlich von den Gegebenheiten ab. Aber oft ist es doch so, dass man verschiedene Artikelarten haben will, um diese unterschiedlich behandeln zu können. Da ist die "Vererbung" von Eigenschaften im Stil der objektorientierten Programmierung nahe liegend.
So unterscheiden wir interne technische Unterlagen, Organisationsrichtlinien und technische Unterlagen von Kunden und Lieferanten. Diese alle haben weitgehend gleiche Properties, werden aber mit unterschiedlichen Workflows behandelt und werden auch visuell durch unterschiedliche Icons gekennzeichnet.
Man muss dabei berücksichtigen, dass es ja nicht nur die "sichtbaren" Properties gibt, mit denen man die Formulare füllt. Es gibt ja auch viele Properties, die weniger Beachtung finden und allen Artikelarten gemeinsam sind wie "date created" und "date last modified".
Nicht zuletzt ist es eine Frage der Geschwindigkeit: Wenige vertikale Ebenen zu durchsuchen geht schneller als viele horizontale Klassen zu durchsuchen. Habe ich vier Klassen mit je 4 Elementen, so habe ich im Mittel vier Suchschritte. Habe ich die gleichen 16 Elemente in einer flachen Anordnung, so benötige ich im Mittel 8 Suchschritte.
Das gleiche gilt übrigens auch für den Regelbaum im Access Manager...
------------------
Rainer Schulze

[Diese Nachricht wurde von Rainer Schulze am 18. Feb. 2015 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Rainer,

danke für deinen Input!

Ich versteh voll und ganz was Du meinst.

Aber verwendet ihr auch "abstracte" Items?

Wir haben für unsere CAD Items ein "Design Item" welches im BMIDE vom Item abhängt. Unter diesem Design Item hängen dann 3 weitere Items. Und um dieses Desing Item geht es mir, mit dem bin ich nicht ganz happy. Wenn ich jetzt auf einem der 3 untergeordnete Items ein zusätzliches Property benötige, dann wird man das vermutlich am Design Item anbringen, aber dann kanns ja auch sein, dass ich dieses Property nicht zwingend auf den anderen 2 ItemTypen benötige.

Ich bin nicht unbedingt ein Freund davon Properties über den Stylesheet auszublenden, denn der User kann ja über die Eigenschaften trotzdem an die Properties ran.

Grüße,

Thomas

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von tom-nx:
Wir haben für unsere CAD Items ein "Design Item" welches im BMIDE vom Item abhängt. Unter diesem Design Item hängen dann 3 weitere Items. Und um dieses Desing Item geht es mir, mit dem bin ich nicht ganz happy. Wenn ich jetzt auf einem der 3 untergeordnete Items ein zusätzliches Property benötige, dann wird man das vermutlich am Design Item anbringen, aber dann kanns ja auch sein, dass ich dieses Property nicht zwingend auf den anderen 2 ItemTypen benötige.

---

Wenn Properties nur am DesignItem.ersteAbleitung gebraucht werden dann gibt man die nur an dieses BusinessObject.

Ist diese Ableitung NonPrimary kann man die auch in Prinmary umwandeln.

Frei nach Mark Hoover: "Verwende Abstract Classes wo geht".

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

>>Aber verwendet ihr auch "abstracte" Items?

Jetzt müsste man darüber philosophieren, was an einem Item-Typ "abstrakt" ist.
Aber der Grundtyp "Item" ist eine solche übergeordnete Klasse, die ihre Eigenschaften an untergeordnete Klassen vererbt.

So zahlreiche Artikelarten haben wir nicht, dass wir da große Überlegungen für eine vielfältige Struktur benötigen.
Wir haben nur einen Item-Typ, der nicht direkt vom "Item" abgeleitet wird.

Ich staune manchmal, was alles an feinfühligen Unterscheidungen hier im Forum diskutiert wird.
Aber unsere Datenbank umfasst nur etwa 80.000 Artikel und unsere Firma hat nur etwa 400 Beschäftigte.
In großen Firmen mag es durchaus vielfältigere Bedürfnisse geben als bei uns.

>>Wenn ich jetzt auf einem der 3 untergeordnete Items ein zusätzliches Property benötige, dann wird man das vermutlich am Design Item anbringen, aber dann kanns ja auch sein, dass ich dieses Property nicht zwingend auf den anderen 2 ItemTypen benötige.

Letzteres muss man natürlich abwägen. Aber dann würde ich dieses Property eben nur an den besonderen Untertyp hängen.
Genau das ist ja der Grund für die hierarchische Struktur:
Was gemeinsam ist, wird von oben nach unten vererbt.
Was spezifisch für einen Untertyp ist, wird nur dort deklariert.
Aber Vorsicht: Sollte es sich später herausstellen, dass das Property doch in allen Klassen benötigt wird, so darf es nicht drei Properties mit gleichem Namen (= EINE gemeinsame Datenbank-Tabelle!) geben.
Dann vielleicht lieber ein paar leere Einträge in der Datenbank verschwenden.

------------------
Rainer Schulze

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

item.PNG

Hallo Thomas,

danke dir!

So wie ich dich verstehe bist Du ein Freund von Abstracten Classes 

Aber was machst Du im Falle, dass Properties nicht an alle untergeordentet ItemTypen gebraucht werden?

Ich hab irgendwie das Gefühl, dass man flexibler ist wenn man kein abstractes Item verwendet.

Anbei ein Bild, das verdeutlicht die Lage ein wenig.

Im Internet hab ich nichts gefunden wo der Mark Hoover die Gründe dafür nennt, gibts da etwas?

Grüße,

Thomas

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Rainer,

Zitat:

---

Jetzt müsste man darüber philosophieren, was an einem Item-Typ "abstrakt" ist.
Aber der Grundtyp "Item" ist eine solche übergeordnete Klasse, die ihre Eigenschaften an untergeordnete Klassen vererbt.

---

Ich denke das Bild welches ich hochgeladen habe macht die Sache deutlicher.

Zitat:

---

Ich staune manchmal, was alles an feinfühligen Unterscheidungen hier im Forum diskutiert wird.
Aber unsere Datenbank umfasst nur etwa 80.000 Artikel und unsere Firma hat nur etwa 400 Beschäftigte.
In großen Firmen mag es durchaus vielfältigere Bedürfnisse geben als bei uns.

---

Na so viele Item Typen haben wir jetzt auch nicht :) Ich denke da gibts Firmen die wesentlich mehr haben.

Zitat:

---

Letzteres muss man natürlich abwägen. Aber dann würde ich dieses Property eben nur an den besonderen Untertyp hängen.
Genau das ist ja der Grund für die hierarchische Struktur:
Was gemeinsam ist, wird von oben nach unten vererbt.
Was spezifisch für einen Untertyp ist, wird nur dort deklariert.
Aber Vorsicht: Sollte es sich später herausstellen, dass das Property doch in allen Klassen benötigt wird, so darf es nicht drei Properties mit gleichem Namen (= EINE gemeinsame Datenbank-Tabelle!) geben.
Dann vielleicht lieber ein paar leere Einträge in der Datenbank verschwenden.

---

Und genau das ist der Grund warum ich da lieber 3 eigenstängide ItemTypen anlegen möchte, die direkt vom Typ Item kommen, aber ohne dieses "Zwischenitem"

Danke!

Thomas

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von tom-nx:
...So wie ich dich verstehe bist Du ein Freund von Abstracten Classes  

Aber was machst Du im Falle, dass Properties nicht an alle untergeordentet ItemTypen gebraucht werden?

Ich hab irgendwie das Gefühl, dass man flexibler ist wenn man kein abstractes Item verwendet.
...
Im Internet hab ich nichts gefunden wo der Mark Hoover die Gründe dafür nennt, gibts da etwas?

---

Natürlich gibts Fälle wo man dann abwägen muss ( man könnte auch noch weitere zusätzliche abstrakte Klassen einführen ... ).
Man kann Properties auch auf Visible=false setzen, ist auch eine Möglichkeit
( nicht nur einen StyleSheet Schmäh machen - den mache ich übrigens aus Prinzip nicht ).
D.h. die Property ist in der AbstractClass und in dem einem BusinessObject wo man sie nicht will/braucht eben "nicht sichtbar".

Die Behauptung, alles in ein BO zu stecken wäre flexibler teile ich nicht.
Schliesslich stopst du auch nicht alle Properties in die Item / ItemRevision Klasse, das wäre dann am flexibelsten ...

http://www.hoovernebrig.com/data/if_i_were_king.pdf [Seite 30]
Stimmt schon dass nicht explizit drinsteht warum, aber ich sehe es auch so ...

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Danke Thomas!

Da fehlt mir einfach noch das Wissen wie man das besten im BMIDE umsetzt.

Zitat:

---

( nicht nur einen StyleSheet Schmäh machen - den mache ich übrigens aus Prinzip nicht ).

---

Genau das war aber der Auslöser für diesen Beitrag, weil Siemens das genau so gemacht hat und das hat mir nicht gefallen!

Warum man da nicht z.B. diesen Ansatz mit visible=false gewählt hat kann ich nicht sagen.

Wenn es da saubere Lösungen gibt, hab ich mit diesem "DesignItem" kein Problem!

Das Zeug ist einfach echt schon so umfangreich, dass mir manchmal vorkommt selbst Siemens weiß nicht alles 

Ich denke man braucht einfach sehr viel Erfahrung im Umgang mit dem BMIDE.

Danke nochmal für die Inputs!

Grüße,

Thomas

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

TC83_BMIDE_inheritedPropertyHidden.png

Im Anhang ein Beispiel fürs Visible / NonVisible setzen ...

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Super, vielen Dank!

Grüße,

Thomas

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP