Wozu sind Attribute gut ?

[Phoenix]

Please, don't feed the Troll.

[squetk]

Zitat:

ich weiß, daß ich es garantiert nichts so machen würde.

Zitat:

dies in jeder Kundendatenbank von Hand nachgetragen werden musste.

Textinformationen gehören definitiv in eine Datenbank, genau dafür ist sie da. Und die beschriebenen Probleme bei Felderweiterungen etc. stellen sich bei der Nutzung eines guten ORM überhaupt nicht.

[Elvis]

Zitat:

Zitat von squetk (Beitrag 1222225)

Zitat:

ich weiß, daß ich es garantiert nichts so machen würde.

Zitat:

dies in jeder Kundendatenbank von Hand nachgetragen werden musste.

Textinformationen gehören definitiv in eine Datenbank, genau dafür ist sie da. Und die beschriebenen Probleme bei Felderweiterungen etc. stellen sich bei der Nutzung eines guten ORM überhaupt nicht.

Hmm...
Ich finde für solche Infos sind Resources immer noch ideal, weil parallel zur DB versionierbar. Man kann mit 2 Versionen der Software auf der gleichen DB arbeiten ohne, dass man Side effects für dogmatischen Käse riskiert. Schlimm genug wenn man in den Situationen Side effects für tatsächlich sinnvolle Dinge bekommt.
Und sorry, aber Command Labels etc. in einer DB zu halten ist Käse.
Wenn man die von einem Release zum anderen wirklich umbenennen will, dann werden halt die ResX angepasst.

[Phoenix]

Zitat:

Zitat von Elvis (Beitrag 1222234)

Ich finde für solche Infos sind Resources immer noch ideal, weil parallel zur DB versionierbar. Man kann mit 2 Versionen der Software auf der gleichen DB arbeiten ohne, dass man Side effects für dogmatischen Käse riskiert.

Grundsätzlich korrekt. Außer natürlich, der Kunde will translations für sich angepasst haben.

Wir haben die Translations tatsächlich auch in der Datenbank. Und wir haben pro Version Updatescripte, die geänderte Translations anpassen, sofern sie noch den Originalwert haben.

Ist zwar was mühsam, aber funktioniert.

[Elvis]

Warum nicht einfach Resource DLLs mit liefern? Gerade in .Net ist das doch sehr einfach.
aber das wird OT.

Zum Thema:
Attribute sind Metadaten direkt am zu beschreibenden Code-Element. (Eigenschaft, Typ, Methode, ...)
Das heißt, man kann die Mittel der Sprache/Runtime um zusätzliche Punkte erweitern, ohne dass es zu fremdartig wirkt.

AOP-Frameworks können Attribute nutzen um sehr einfach die zu erweiternden Teile zu finden. Derjenige, der den Code liest, kann aber auch sehr einfach sehen was passiert. (Solange diese Attribute sinnvolle Namen und Parameter haben)

Ich selbst habe einen Build Task für C# geschrieben, mit dem man ein exaktes Gegenstück zu DllImport bekommt.
Da es sich in der Bedienung und Benennung eng an das vom Framework gestellte DllImport hält, fällt es eigentlich gar nicht als etwas "fremdes" auf.

PostSharp nutzt Attribute um Aspekte an bestimmte Code-Elemente zu binden. Auch das ist IMO sehr leserlich und verständlich.

Lustigerweise finde ich es gerade bei ORMs ziemlich daneben. Da Attribute-basierte Mappings nicht beim Kunden vom Kunden oder einem Consultant angepasst werden können. Aber ich bin wohl einer der ganz wenigen, die Mapping by Code nur während der ersten Entwicklungsphasen einsetzen...

Da Delphi Maschinen-Code erzeugt sind die wirklich mächtigen Use-Cases sicherlich so sau schwer zu implementieren, dass man es besser sein lässt.
Aber nicht alle Metadaten werden zum Verändern des Kompilats benötigt. ;-)

[squetk]

Zitat:

Ich finde für solche Infos sind Resources immer noch ideal, weil parallel zur DB versionierbar.

Zitat:

Warum nicht einfach Resource DLLs mit liefern?

Weil ich mich damit zu sehr in Abhängigkeiten begebe.
Clients meiner Anwendung sollen in Zukunft nicht mehr zwangsläufig unter Windows laufen.
Und Begrifflichkeiten kann dann der (autorisierte) Kunde bequem anpassen.

Attribute sind Konstrukte für den Entwickler.
Ich müsste das Programm neu kompilieren, falls dem Kunden eine Beschreibung nicht passt, die ich in einem Attribut hinterlegt hab.

[Uwe Raabe]

Zitat:

Zitat von squetk (Beitrag 1222225)

Textinformationen gehören definitiv in eine Datenbank, genau dafür ist sie da. Und die beschriebenen Probleme bei Felderweiterungen etc. stellen sich bei der Nutzung eines guten ORM überhaupt nicht.

Wenn es sich bei diesen "Textinformationen" z.B. um die Liste der verfügbaren Maschinen beim Kunden handelt, stimme ich dir zu. Wenn es aber um die passende Übersetzung des Labels "Stückzahl" geht, hat das nur in Ausnahmefällen was in der (Kunden-)Datenbank verloren (nur meine Meinung). Ach ja, ein ORM nutzt wohl auch nicht jeder - von einem guten ganz abgesehen. Das sollte aber jetzt nicht in einen Glaubenskrieg ausarten.

Es könnte sich als etwas schwierig erweisen, die Screenshots für die Dokumentation zu machen, wenn der Kunde quasi die gesamten Beschriftungen eines Forms verändern kann. Womöglich ergeben sich dabei ganz andere Bedeutungen und das Programm tut nicht mehr das, was man erwarten würde.

Ich stelle damit nicht grundsätzlich die Speicherung von Übersetzungen in einer Datenbank in Frage, wenn das verwendete Übersetzungs-Framework dies so realisiert.

Aber ich glaube wir schweifen ab.

[Elvis]

Zitat:

Zitat von squetk (Beitrag 1222272)

Attribute sind Konstrukte für den Entwickler.
Ich müsste das Programm neu kompilieren, falls dem Kunden eine Beschreibung nicht passt, die ich in einem Attribut hinterlegt hab.

War so nicht gemeint. (Also Attribut-basiert) Ich weiß nicht, ob man in Delphi Ressource-Strings in Attributen nutzen kann, würde es aber annehmen.
Dann würde man die App nicht neu kompilieren müssen. Einfach eine Ressource-GUI geschnappt und die Texte anpassen.
Sicherlich wären Dinge, die eigentlich konfigurierbar sein sollten, aber trotzdem in ein Attribut gesteckt wurden, zu den Dingen für die Attribute eben nicht gut sind. IMO gehören viele ORM-bezogene Dinge dazu. (Also die Teile, die das Mapping zum phys. DB-Modell darstellen)

Bei P. denke ich, dass sie an solche Dinge wie effizientes Caching der Texte gedacht haben.
Das vergisst man bei diesen Texten-in-DB-Lösungen gerne: Die App darf sich jetzt einen Wolf abfragen nur um ein paar Texte darstellen zu können.

[Der schöne Günther]

Zitat:

Zitat von Uwe Raabe (Beitrag 1222273)

Es könnte sich als etwas schwierig erweisen, die Screenshots für die Dokumentation zu machen, wenn der Kunde quasi die gesamten Beschriftungen eines Forms verändern kann. Womöglich ergeben sich dabei ganz andere Bedeutungen und das Programm tut nicht mehr das, was man erwarten würde.

Vor dem Problem stehe ich auch bald, danke schonmal für den Warnhinweis :), spontan hätte ich das Problem nicht gesehen (dafür schon jetzt jede Menge andere :roteyes:).

[squetk]

Zitat:

hat das nur in Ausnahmefällen was in der (Kunden-)Datenbank verloren

Ich denke, wenn ich es auf "kundenspezifische Begrifflichkeiten" einschränke, kommen wir auf einen Nenner. Den Ok-Button würde ich mir auch nur ungern umbenennen lassen :-D
Aber auf diese Art ist z.B. bei uns auch der Support in der Lage, ohne Programmierung eine Anwendung auf einen Kunden anzupassen.

Zitat:

Die App darf sich jetzt einen Wolf abfragen nur um ein paar Texte darstellen zu können.

Natürlich werden diese Art Informationen gecached - auch das sollte ein gutes O/R-Mapping leisten.

Aber wir schweifen tatsächlich ab. Die Quintessenz meiner Meinung ist dass Attribute nur Deklarationsinformationen darstellen sollten und keine Begrifflichkeiten, mit denen der Anwender hantiert.