Pracuję z bazą danych, w której projektanci postanowili oznaczyć każdy stół kolumną bitową IsHistorical. Nie ma znaczenia dla prawidłowego modelowania i nie ma możliwości zmiany schematu.

Powoduje to pewne tarcia podczas tworzenia ekranów CRUD, które współdziałają z właściwościami nawigacji. Nie mogę po prostu wziąć produktu, a następnie edytować jego EntityCollection. Muszę ręcznie pisać sprawdzenia IsHistorical w całym miejscu i doprowadza mnie to do szału.

Dodatki są również okropne, ponieważ do tej pory napisałem wszystkie ręczne sprawdzenia, aby sprawdzić, czy dodatek jest po prostu miękki, więc zamiast dodawać zduplikowaną jednostkę, mogę po prostu przełączać IsHistoric.

Trzy opcje, które rozważałem to:

Modyfikowanie szablonów t4 w celu uwzględnienia sprawdzeń i synchronizacji IsHistorical.

Przechwytuj usuwanie i dodatki w ObjectContext, przełącz kolumnę IsHistorical, a następnie zsynchronizuj stan obiektu.

Zapisz się na wydarzenie AssociationChanged i przełącz tam kolumnę IsHistorical.

Czy ktoś ma jakieś doświadczenie lub może polecić najbardziej bezbolesne podejście?

Uwaga: Tak, wiem, to jest złe modelowanie. Przeczytałem te same artykuły na temat kasowania, które masz. To śmierdzi Muszę poradzić sobie z tym wymogiem, ale tak jest. Chcę tylko najbardziej bezbolesnej metody radzenia sobie z miękkimi usuwaniami bez pisania tego samego kodu dla każdej właściwości nawigacji w mojej bazie danych.

Uwaga # 2 Odpowiedź LukeLeda jest poprawna pod względem technicznym, chociaż zmusza cię do naprawdę złego, biednego mans ORM, bez wykresu. Problem polega na tym, że teraz muszę zgrać wszystkie „usunięte” obiekty z wykresu, a następnie wywołać metodę Usuń nad każdą z nich. To tak naprawdę nie uratuje mi tak ręcznego ceremonialnego kodowania. Zamiast pisać podręczne kontrole IsHistoric, teraz gromadzę usunięte obiekty i przeglądam je.