Cześć!
Pisze sobie projekcik asp.net core. Jest on podzielony na kilka projektów. Między innymi posiadam główną aplikację asp, oraz bibliotekę odpowiedzialną, za dostarczanie obiektów modeli. Mając model **Customer używam, klas DTO np. CustomerCreateModel. Za dodawanie i updatowanie odpowiada klasa CustomerStore, która ma m,in. metodę ** public bool Create(CustomerCreateModel customerCreateModel) Wewnątrz używam Automappera do przepisywania wartości DTO -> Model oraz Model -> DTO. Generalnie teraz zastanawiam się nad tym, jak zorganizować te mappery. Ogólnie z tego co wyczytałem w sieci, odchodzi się od stosowania statycznych struktur AutoMappera na rzecz DI. Wszystkie przykłady pokazują, że w klasie Startup.cs w projekcie ASP rejestruje się AutoMappery i tyle. Niemniej oni wszyscy używają tych mapperów w kontrolerach gdzie są wstrzykiwane. Nie sądzę, że to jest ok - chciałbym ukryć fakt, że w ogóle jest jakieś mapowanie robione w CustomerStore. Jeśli w konstruktorze CustomerStore przyjmował bym IMapper to za kreacje obiektu CustomerStoreodpowiadał by DI, który konstruuje całą aplikacje asp. Co w przypadku jak użyję mojej biblioteki, w której mam modele jako warstwa modeli do aplikacji WPF czy WinForms lub zupełnie inaczej - do jakiegoś serwisu do operacji wsadowych? Wtedy będzie trzeba przygotować dodatkową aplikacje/kod do kreacji moich obiektów DAL, żeby było wiadomo jakie implementacje IMapperów wstrzyknąć.
Macie pomysł jak to zorganizować, by wstrzykiwanie mapperów odbywało się w bibliotece modeli, ale nie koniecznie sztywno tworzone w konstruktorach danych DAL'i . Chciałbym inaczej mówiąc Stworzyć jakąś fabrykę w bibliotece modeli, która na podstawie konfiguracji zwróci mi odpowiedni mapper i wstrzyknie do DAL'a, a z kolei ta fabryka zostanie poproszona o daną implementacje DAL przez DI z aplikacji asp.mvc lub przez inną np. serwis windowsowy. Robiliście coś takiego? Co sądzicie o takim podejściu? Z góry dzięki za Wasz czas!