@TwojHimars: Code First Approach i kilka środowisk na kórych kolejno testowane sa zmiany

@zibizz1: Też tak robię, ale jest klika problemów z tym podejściem. Dla uproszczenia załóżmy, że mamy 2 środowiska dev i prod. Robimy jakieś zmiany na środowisko dev mamy np. 3 migracje do przodu względem proda. Nie chcemy tego wypuszczać na proda, a trzeba dodać migracje na prodzie, która jest potrzebna do fixa. Wtedy wiadomo robimy branch z proda i dodajemy tam migracje, a później trzeba na devie cofać te migracje, żeby najpierw zaaplikować tą z fixa. Masz jakieś tipy, żeby to usprawnić?

@TwojHimars a u Ciebie jaka złożoność/problemy występują, bo nie napisałeś żadnych konkretów?

@smalczyk1: to co testujesz powinno być testem integracyjnym aplikacja - baza na działającej infrastrukturze. Testowanie tego mockując zależność od DB boli na co sam zwracasz uwagę - jakieś to takie, dziwne, trudne, nienaturalne.
Twój test tak naprawdę nie daje Ci żadnej pewności, że twój kod dobrze działa.
1. Sprawdzasz czy Attach działa? Do tego testy napisali twórcy EFa.
2. Sprawdzasz czy można przypisać "Deleted" do State? Jak wyżej.
3. Sprawdzasz czy SaveChangesAsync działa? Znowu jak wyżej.

To czego nie sprawdzasz, a powinieneś to współpraca wersji EFa jaką masz z bazą danych której używasz. Tego twórcy EFa/bazki już tak nie sprawdzą. I to sprawdzisz testem integracyjnym.
Testy jednostkowe są do sprawdzania kodu działającego w obrębie procesu, a mocki do stawiania makiet zależności pozaprocesowych i niezarządanych (tj. takich do którego dostęp mają też inne aplikacje).
Baza danych to najczęściej (bo nie zawsze!) zależnośc pozaprocesowa zarządzana (tzn dostępna tylko z jednej aplikacji).

@smalczyk1: W skrócie, na podstawie tego co napisałeś, wydaje się że wystarczy Ci jeden test integracyjny gdzie usuniesz jakiś konkretny resource i w tym samym teście sprawdzisz że go już tam nie ma (i zrobisz to wołając swoją działającą aplikację, która gada do działającej bazy danych).
Test integracyjny pokryje Ci działanie handlera i komunikację aplikacja-baza w tym konkretnym przypadku.

W bardzo wielkim skrócie:
1. unit testy najlepiej nadają się do sprawdzania zakodowanego procesu decyzyjnego (np. czy podany ciąg znaków to poprawny pesel?)
2. Testy integracyjne najlepiej nadają się do sprawdzania współpracy pomiędzy aplikacją a jej zależnościami pozaprocesowymi zarządzanymi
3. Contract testy najlepiej nadają się do sprawdzania współpracy z zależnościami pozaprocesowymi niezarządzanymi.
pewnie można jeszcze to jakoś podzielić/dopisać a ktoś może przyjść i pewnie się do czegoś d-----ć bo testowanie to nie jest coś gdzie wszystko zostało powiedziane. Powyższe zasady jednak dobrze wytrzymują próbę czasu.

@TomaszWKS: efcore pozwala kilkoma sposobami na ustawienie relacji pomiędzy modelami -> https://www.learnentityframeworkcore.com/configuration/data-annotation-attributes/foreignkey-attribute

Piszesz, że Client ma guid jako klucz podstawowy, a następnie, że dostajesz go w żądaniu http w formie int.

To akurat repository pattern, walidacja (nie ma osobnego dewelopera, który się nią zajmuje) tego guid odbywa sie w innym miejscu


`public void CreateTruckForCoworker(Guid coworkerId, Truck truck)
{
truck.CoworkerId = coworkerId;
Create(truck);
}`

@100x: https://stackoverflow.com/questions/7712794/entity-framework-codefirst-table-pluralization

@100x: 3. Trzeba jeszcze zarejestrowac LazyProxy w startupie

@100x: Wydaje mi się że się da z pomocą entity framework ale nie wiem czy dobrze zrozumiałem problem

@Aryo:
Przykład. Jest funkcja

CREATE OR REPLACE FUNCTION usunKonto (user_id integer)
RETURNS TABLE(res_status integer, res_user_id BIGINT)
AS $xd$
declare
jakasZmienna integer;
BEGIN
DELETE FROM user WHERE id = user_id;
res_status := 1;
res_user_id := user_id;
RETURN SELECT res_status, res_user_id;
END;
$xd$
LANGUAGE plpgsql;

Używam tego jak zwykłe zapytanie: SELECT * FROM usunKonto(2137);


Chciałbym tą część:
DO $xd$
declare
jakasZmienna integer;
BEGIN
DELETE FROM user WHERE id = user_id;
res_status := 1;
res_user_id := user_id;
RETURN SELECT res_status, res_user_id;
END;
$xd$
LANGUAGE plpgsql;

używać jako funkcję anonimową ale widzę, że nie mogę przekazywać parametrów ani pobierać rezultatów z poziomu spring jpa.

@MarcelFerry:

var x = db.Entity.Where(x => x.Costam).Select(x => ).FirstOrDefault()

EF wtedy wygeneruje selecta wykorzystującego tylko kolumny, które w Select() bezpośrednio wywołasz. Nie znam sposobu, żeby wyciągnąć wszystko oprócz pojedycznego property

@MarcelFerry:
A może w ten sposób? Jeżeli nie chcesz udostępniać wszystkich pól w konstruktorze lub/i setterach to można zrobić builder jako nested class.

`
public static IQueryable WithoutByteArray(this IQueryable source)
=> source.Select(b => new Book
{
Id = b.Id,
Name = b.Name,
//...
});
`

W EF masz Skip i Take.

@Hektorrr: Dodam, że zestaw tych wszystkich książek normalnie wyceniony jest na £1,119.85.
Tak więc £14 funtów to prawie jak za darmo a jak wiadomo za darmo to uczciwa cena.

@Hektorrr: szkoda, że nie fizyczne wydanie ( ͡° ʖ̯ ͡°)

@vanguard2727: Po to żeby nie powtarzać deklaracji propert takich jak id. Entity jest abstrakcyjną klasą. Nie reprezentuje żadnej tabeli. Ucz się z materiałów M$ najlepiej w języku angielskim.

@vanguard2727: Raczej staram się unikać lazy loadingu. Szybko prowadzi do n+1 problemów. Najlepiej robić wyspecjalizowane dtosy oraz korzystać z metody include z dbcontext kiedy chcesz pobrać coś wymaganego dla danej funkcjonalności.

@simple_rick: G

@vanguard2727 daruj to sobie

@vanguard2727: Możesz pominąć. Na rozmowie kwalifikacyjnej Cię mogą zapytać o to i wystarczy, że będziesz kojarzył temat.

Jeśli chodzi o performance EF, to ważniejsze na początek jest np wiedzieć, kiedy używasz Lazy Loadingu vs Eager loading, co robi AsNoTracking,, jak zrobić BulkInsert

@ShadowkhaN: chodzi ci o dwie bazy jedna read druga write?

@PortowySzczur: Coś takiego zadziałało, utworzylo dwie kolumny FromId oraz ToId

`internal class Table
{
public Guid ID { get; private set; }
}


internal class TableWorkflow
{
public Table From { get; private set; }
public Table To { get; private set; }
}


internal class TableWorkflow
{
public Table From { get; private set; }
public Guid FromId { get; private set; }
public Table To { get; private set; }
public Guid ToId { get; private set; }
}


public void Configure(EntityTypeBuilder

modelBuilder)
{
modelBuilder.HasOne(k => k.From)
.WithMany()
.OnDelete(DeleteBehavior.Restrict);

modelBuilder.HasOne(k => k.To)
.WithMany()
.OnDelete(DeleteBehavior.Restrict);

modelBuilder.HasKey(k => new { k.FromId, k.ToId });
}`

@kazik-: mozecie zamknac nawet teraz

@kazik-: co to sprzedawcy garnków wzięli się za wciskanie ludziom kursów z programowania?
"Tylko dzisiaj za jedyne 6 stów dostaniesz komplet garnków i materac o łącznej wartości 4300" :D

@inrain88: uzywamy podejscia code-first.

@inrain88: Tak jak napisali koledzy wyżej, code-first i migracje.
Początkowo mieliśmy database first, ale w momencie gdy projekt i model się mocno rozrosły to nieprzewidywalne zachowanie plików .edmx (szczególnie przy mergowaniu branchy) stało się mocno uciążliwe i przeszliśmy na code-first.

@Anon95 musisz mieć jakąś kolumnę/tsbele, która łączy jedno id z drugim.

@WielkiElektronig: Chodzi ci o coś takiego? Tylko jak to połączyć z bazą Idenity w kodzie.

@kazik-: ile zarabia mid w c# poza Warszawą?

@cecyl: tyle ile zarabia mid w c# poza kazdym miastem wojewódzkim

@kazik-: bardzo fajny materiał - dowiedziałem się kilku przydatnych rzeczy :D

@Anon95: jeżeli to projekt do nauki to sklep będzie ok. Możesz sobie wymyślić jakiś specyficzny sklep sprzedający np jakoś produkty konfigurowalne albo w modelu subskrypcyjnym żeby skomplikować trochę logikę aplikacji.

@Anon95: zrób apke która zapisuje filmy YT na playlistę na zadanym koncie YT. Lizniesz komunikację z zewnętrznymi API, jakieś oauth2. Powinno ci to zająć tydzień lekką ręką

@PrawyKuba: Oczywiście po napisaniu na mirko znalazłem rozwiązanie. ( ͡º ͜ʖ͡º)

Dla potomnych:

`
builder
.HasKey(p => p.Id);

builder
.Property(p => p.Id)
.HasConversion(
v => v.Value,
v => new ProductId(v)
);
`

https://paste.ofcode.org/398UPBxcEt6hJpGQynFG8XS