[pepepanpatryk]

Jakie macie metody mapowania obiektów domenowych na obiekty, z których korzysta Entity Framework?
Używanie bezpośrednio obiektów z DbContext może i jest wygodne, ale w przypadku podpinania nowego softu do istniejacego schematu bazy danych(który np. jest skopany i nie ma możliwości jego zmiany), może nieźle popsuć sens od strony logiki biznesowej.

#programowanie #csharp #entityframework

[budyn]

@pepepanpatryk: Normalnie z palca. Nie polecam używać obiektów bazodanowych poza zapisywaniem i odczytywaniem z bazy. Do mapowania można też użyć np AutoMappera

[l.....w]

@pepepanpatryk: AutoMapper

[pepepanpatryk]

@budyn @lowca_randroidow: Automapera używam do mapowania na DTO-sy zwracane z API. Aczkolwiek może faktycznie spróbuje użyć go z EF.

Myślałem nad koncepcja, by dla każdego zapytania(select), czy operacji(insert, update, delete) tworzyć takie jakby query objecty, gdzie przykładowo tworzę sobie obiekt domenowy przetwarzam i odpalam ten query object przekazujac mu jako parametr właśnie mój obiekt domenowy, ale to jak on sobie go już zmapuje do bazy to mnie nie interesuje.
Przykładowy kod:

[budyn]

@pepepanpatryk: Dobry masz pomysł ziomek. Najlepiej w DI zarejestruj sobie dbContext 'in request scope', dzięki temu dostaniesz ten sam dbContext gdziekolwiek go sobie zażyczysz w obrębie jednego requesta. Z tym save changes to jest trochę problemowo, bo w sumie czasami chcesz sobie zapisać dane od razu a czasami nie robi i może być na koniec requestu. Jeśli na koniec to możesz to skonfigurować w DI, żeby przed dispose odbywał się SaveChanges().

[budyn]

@pepepanpatryk: Aha ten drugi pomysł słaby moim zdaniem

[budyn]

@pepepanpatryk: https://mehdi.me/ambient-dbcontext-in-ef6/

[Dworki]

@pepepanpatryk: Automapper ma metode rozszerzająca do query na db context, szukaj w Google jak sie używa(nazywa się jakoś ProjectTo czy jakoś tak i przy select jest fajna opcja bo pobiera tylko to co potrzebujesz z bazy.