EditTeamMeetingTopics » History » Revision 4
Revision 3 (Andreas Kohlbecker, 06/26/2018 11:29 AM) → Revision 4/6 (Andreas Kohlbecker, 07/30/2018 12:19 PM)
# Edit Team Meeting Topics Topics to be discussed in coming meetings. --- ## 1) Widcards usage in service methods >>>> Zu den Wildcards: Anscheinend funktionieren im Editor beide Varianten. Hab es eben ausprobiert. Hatte ursprünglich mit % versucht, da man das bei den Webservices verwenden muss. Zumindest funktioniert dort der * nicht. >>> Stimmt es, dass die Webservices „*“ nicht übersetzen bzw. % die einzige mögliche Wildcard ist? Wenn ja, ist das so gewollt? Ich hätte ja eher die „*“-Suche erwartet. % ist so SQL spezifisch. >> Habs mir angeschaut. Das scheint ziemlicher Wildwuchs zu sein, weil die jeweiligen Implementierer von einzelnen Services das entweder im Blick hatten oder nicht. >> Eine Methode, es zu erzwingen fällt mir gerade leider auch nicht ein, so dass man wohl lediglich durch alle Services durchgehen könnte und checken, ob das SQLize dort implementiert ist. Sollten wir mal besprechen. >> AM > Eigentlich gibt es dafür schon einen Methode:. > eu.etaxonomy.cdm.persistence.query.MatchMode.queryStringFrom(String queryString) TODO: Create ticket ... ## 2) Centralized initialization strategies >> Ich habe schon des öfteren daran gedacht ob es nicht Sinn machen würde die Intialisierungs-Strategien zu zentralisieren. >> Oftmals werden an vielen Stellen die selben verwendet, wobei immer wieder die selben Muster auftauchen. >> Es wäre also auch eventuell möglich die Strategien zu modularisieren. >> Bei Modelländerungen wäre es dann einfacher die entsprechenden Initialisierungsstrategien an zu passen. Wenn wir Klassen kreieren die die Initialisierungsstrategien ausgeben, also quasi ein InitStrategyBuilderFramework, das die property-path Strings liefert würden Refaktoriereungen noch sicher sein können. >> >> All diese Gedanken nur in aller Kürze. Wir können das ja mal Mündlich besprechen. >> >> Viele Grüße >> Andreas > Ich denke auch, dass es Sinn macht das zu zentralisieren! > Vielleicht können wir Anfang nächster Woche uns dazu zusammen setzen. > > Viele Grüße, > Katja > Ja, finde ich auch gut. Habe auch schon paar mal drüber nachgedacht, wie man das machen könnte. Bin gespannt, was ihr für Ideen habt. > > Viele Grüße, > Andreas M. TODO: Create ticket ... ## 3) Discuss/Decide conventions for service method names * get/list/load/find etc. see also [[CdmLibraryConventions#Service-Layer]] TODO: Create ticket ... ## 4) DTOs * Build DTO class hierarchy which bases on EntityDTOBase as parallel model to the cdm model? * Should associated entities be modled in the DTO as UuidAndTitleCache oder TypedEntityReferece ? * ==> build EntityReferece class hierarchy? EntityReferece <----- TypedEntityReferece <--- UuidAndTitleCache (title caches exist only in IdentifiableEntity, whereas TypedEntityReferece is more general) * Discuss https://martinfowler.com/bliki/LocalDTO.html * DTOs are per definition a pattern for remote layers: > (from email conversation DTO Klassen die ihr eigener Object Adapter sind? 25.07.18 14:06) > Die DTOs gehen auf Martin Fowler zurück und der benennt den Zweck von DTOs so: "An object that carries data between processes in order to reduce the number of method calls." (https://martinfowler.com/eaaCatalog/dataTransferObject.html). Es geht also in erster Linie darum, die Performance von Remote-Zugriffen zu verbessern. > > Auch wikipedia nennt dies als primären Zweck (https://en.wikipedia.org/wiki/Data_transfer_object) und ergänzt dies noch durch "The difference between data transfer objects and business objects or data access objects is that a DTO does not have any behavior except for storage, retrieval, serialization and deserialization of its own data (mutators, accessors, parsers and serializers). In other words, DTOs are simple objects that should not contain any business logic but may contain serialization and deserialization mechanisms for transferring data over the wire."