Separate namespaces to avoid ambiguous references
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Stack tecnologico
- csharp
- Ambito
- backend-api-design
Direzione di ricerca
Inizia individuando le estensioni async che contengono AfterMappingAsync e le estensioni di base di Mapster con cui attualmente condividono un namespace e una classe. Esamina i riferimenti e i mappings generati tramite reflection per valutare la modifica del namespace; il lavoro è completato quando le API async e di base possono essere utilizzate senza extern alias o la qualificazione global::Mapster.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
We're using Mapster quite to the maximum extent that is somehow possible. With reflection we dynamically generate base mappings for polymorphic DTOs. Now the issue is, that we need to generate a base implementation that uses AfterMappingAsync.
Since the extensions for that are in the very same namespace and class than the base extensions of Mapster, we have a collision and need to work with extern alias which makes using it a pain. Now we need to also use global::Mapster everywhere else.
Wouldn't it be easier to just put them into a Mapster.Async namespace? I see no benefit for identical namespaces and types other than confusion and unncessary pain to work with it.
Obviously working with Reflection is an edge case here, but still. I feel like this is not very good design. I would avoid using the same namespaces and classes at all costs as it also makes navigation in the source code a lot easier and more transparent.
- Lingua principale
- C#
- Stelle
- 5.2k
- Fork
- 411
- Merge medio
- 3g 4h
- PR unite (30g)
- 3
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di MapsterMapper/Mapster
-
.NET MatrixAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
MapsterMapper/Mapster#1003 ·
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 58/100
MapsterMapper/Mapster#1024 · 1 commento ·
-
[Mapster Tool] Add support for global:: to disambiguate type names in generated mappersForse già presa @DocSvartz l’ha presa 3 giorni fa. Apertaimprovement
Difficoltà 3/5 1-2 giorni Idoneità per principianti 65/100
MapsterMapper/Mapster#1020 · 5 commenti ·
-
Mapster.Tool - PropertySettingBuilder.Map(member, mapFunc, targetPropertyName) method is not working as expected!Forse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 68/100
MapsterMapper/Mapster#1017 · 6 commenti ·
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 57/100
MapsterMapper/Mapster#1007 · 5 commenti ·
Tutte le issue di MapsterMapper/Mapster
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno
-
bug priority: P2
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
IridiumIO/CompactGUI#699 ·
I maintainer di solito rispondono entro 3 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 73/100
I maintainer di solito rispondono entro 1 giorno
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno