Mam aplikację do trzymania i dzielenia się plikami. Użytkownicy mogą tworzyć grupy. Użytkownicy mogą też przyznawać dostęp innym użytkownikom do swoich plików. Zależnie od tego, czy plik jest prywatny, czy należy do grupy, zasady dostępu są inne. Tak to wygląda:
public class File
{
public int Id { get; set; }
public string Name { get; set; }
public string Description { get; set; }
public int Size { get; set; }
public string OwnerId { get; set; } // jeśli plik prywatny
public int DirectoryId { get; set; }
public int? GroupId { get; set; }
public DateTime CreatedAt { get; set; }
public DateTime? LastUpdatedAt { get; set; }
public User Owner { get; set; }
public Directory Directory { get; set; }
public Group Group { get; set; }
public ICollection<Access> Accesses { get; set; }
// jakieś metody odpytujące stan obiektu
}
Model jest anemiczny, jak widać. Mimo to chciałbym mieć w tej klasie File
jakieś metody typu HasUserAccess(string userId)
, aby nie wypychać sztucznie całej logiki do warstwy wyżej. Problem w tym, że jeśli tak ma być, to muszę pobierać nadmiarowe dane (np. plik prywatny nie potrzebuje danych o grupie, w której istnieje, i o jej członkach). Rozwiązaniem jest lazy loading
, ale on jest teraz chyba niezalecany w świecie EF Core ze względu na problemy, które powoduje. Pytanie: czy encja File
powinna być rozbita na UserFile
i GroupFile
z własnymi tabelami i klasami do zapisu i odczytu?