Konstruktory vs metody statyczne - co lepsze w tym przypadku?

0

Cześć,
Mam takie proste zadanie: jest sobie encja A i encja B, i jest między nimi relacja jeden do wielu. Na każdym rekordzie B, który posiada relację do A mają ustawiać się pewne pola na podstawie pól A. Mamy sobie triggery:
-After update na A - jeśli zmieni się któreś z pól, na podstawie których ustawia się pola B;
-Before insert na B - ustawiamy pola na podstawie B;
-Before update na B - jeżeli na B zmieniło się pole z kluczem obcym A.

No i zrobiłem tak:
Przeciążony konstruktor: jeden przyjmuje kolekcję A i na tej podstawie wyszukuje powiązanych B do update'a, drugi przyjmuje kolekcję B i analogicznie wyszukuje powiązanych A, potem mamy wspólną metodę kalkulującą i ustawiającą pola.

Mój lead mówi: weź się nie baw w konstruktory i zrób po prostu metody statyczne.
Jakie macie zdanie na temat zalet i wad obu rozwiązań?

0
  1. Ale konstruktor czego?
  2. Te pola muszą być fizycznie ustawione, nie mogą się zwyczajnie wyliczać w locie?
  3. W ogóle nie bardzo rozumiem jaki setup tam masz. To ma być spójne w bazie? W runtime? Co jeśli wyciągnąłeś encje z bazy a potem się coś zmienia?
  4. Nijak nie widze jak do tego wszystkiego maja się metody statyczne.
1

Nie rozumiem co chcesz osiągnąć ale konstruktor to ma konstruować obiekt wg przekazanych do niego argumentów a nie wyszukiwać jakiś danych i kalkulować rzeczy

1 użytkowników online, w tym zalogowanych: 0, gości: 1