[Khaine]

#csharp #programowanie

ORM yay or nay? Jaki jest teraz najlepszy pod .NET Core?

[damyrade]

@Khaine Entity Framework

[Khaine]

@damyrade: Entity na Core jest taki dobry? Bo przy zwykłym .NET Framework to chyba nHibernate królował? Jak z wydajnością?

[M.....n]

@Khaine:

Bo przy zwykłym .NET Framework to chyba nHibernate królował?

Chyba 10 lat temu

[Khaine]

@Myrten: No to patrząc po ofertach dużo firm ma do utrzymania systemy sprzed 10 lat xD Ludzie zarzucali Entity że nie był code first bodajże. Nie znam się na ORMach, bo nigdy nie miałem okazji ich używać w pełnej krasie -> w projekcie były procki albo statyczne zapytania, żeby wyciskać maksymalną wydajność. ORMów to tylko używali żeby sobie zmapować kolumny na DTO.

[Koliat]

@Khaine: efcore jest bardzo spoko, z innych prostych ormow dapper jest bardzo przyjemny jeszcze, roboty StackExchange

[M.....n]

@Khaine: To lepiej już naucz się Fortrana i Cobola, praca w NASA czeka xD
https://www.geek.com/news/nasa-seeks-programmer-fluent-in-60-year-old-languages-to-work-on-voyager-1638276/

[ghostface]

@Khaine: pełny ORM tylko EF Core. W niektórych przypadkach Dapper, który jednak nie jest pełnoprawnym ORMem.

[Khaine]

@ghostface: Dapper wygląda na coś w stylu "masz tu wywołaj prockę/zapytanie i zrzutuj mi to co wypluje na taki obiekt". Z grubsza to jest coś co lubię najbardziej, bo skomplikowane rzeczy jednak preferuję trzymać po stronie bazy. Łatwiej je modyfikować i zawsze będą szybsze.

[Mazowia]

@Khaine: EF miał ułatwić pracę a zrobili z tego straszną kobyłę i wdrożenie zajmuje sporo czasu. Lubię dappera ale komercyjnie to chyba wszędzie EF jest ( ͡° ʖ̯ ͡°)

[Khaine]

@Mazowia: A jak wydajnościowo? EF dużo jest gorszy od np. procki wmontowanej w bazę danych zwracającej tablicę?

[Mazowia]

@Khaine: Tego nie wiem ale jak się dowiesz to daj znać ( ͡° ͜ʖ ͡°)

[Khaine]

@Mazowia: Musielibyśmy zrobić testy z chłopakami, może kiedyś ( ͡° ʖ̯ ͡°) Ale i tak wolę trzymać skomplikowane rzeczy w bazie, dużo łatwiej to potem poprawiać. Nie trzeba rekompilować programu i robić redeploy. Nawet u klienta na prodzie można poprawić coś z marszu w ten sposób. No i łatwiej równolegle pracować przy tym wszystkim bo np. jeden siedzi w bazie a drugi w aplikacji i nie

[lukpep]

@Khaine: no no... a testowanie tej logiki co zawierasz w prockach? A refaktor? A utrzymanie? Imho zdecydowanie lepiej miec jedno zrodlo kodu z logika biznesowa - kod aplikacji.

[Khaine]

@lukpep: No, jedno źródło kodu, ciekawe tylko jak będzie chodzić? ¯\(ツ)_/¯ Nie wiem jak jest teraz z tymi ORMami (dlatego się pytałem) ale ostatni raz jak chłopaki podglądali profilerem co ORM generuje za zapytania to przestali ich używać, bo to się nie nadawało do niczego innego niż pod CRUD dla stronki o kotkach i pieskach, a nie mielenie terabajtów danych. Ale może się poprawiło coś od tego czasu, bo

[lukpep]

@Khaine:

Ale może się poprawiło coś od tego czasu, bo to było z 2-3 lata temu

Ja robie crudy o pieskach i kotkach co prawda ale nic nie stoi na przeszkodzie zeby w razie jakies zapytanie ze strony ORMa jest malo wydajne go wspomoc nawet raw

[Khaine]

oczywiscie ze nie - dlatego sa testy integracyjne, E2E itp. Ale ok - zgodzmy sie ze mamy inne podejscie do testow po prostu.

@lukpep: Ja jeszcze nie widziałem projektu w którym bym czarno na białym zobaczył, że testy coś pomogły. Rzeczy w których do tej pory robiłem były wydajnościowo wymagające, ale stosunkowo proste same z siebie, więc te testy niewiele by pomogły. Inna sprawa, że ciężko by je nawet było wmontować,