Как определить, нужен ли TenantId класс ребенка или GrandChild? - PullRequest
0 голосов
/ 26 ноября 2018

Допустим, у вас есть Арендатор, у которого много пользователей, у которых много учетных записей, у которых много транзакций.

Как далеко вниз по дереву вы добавляете свойство TenantId?
Как далеко вниз делает деревоВы добавляете UserId?
Или вам нужен только родительский идентификатор?

Предположим, что пользователь никогда не будет намеренно обращаться к дочерней сущности без предварительного доступа к ее родителю.В слаге это было бы что-то вроде: baseurl.com/accounts/{accountId/transactions/{transactionId}

public class Tenant
{
    public long Id { get; set; }
    public string Name { get; set; }
    public virtual ICollection<User> Users { get; set; }
    public virtual ICollection<Account> Accounts { get; set; }
    public virtual ICollection<Transaction> Transactions { get; set; }
}

public class User
{
    public long Id { get; set; }
    public long TenantId { get; set; }
    public string Name { get; set; }
    public virtual ICollection<Account> Accounts { get; set; }
}

public class Account
{
    public long Id { get; set; }
    public long TenantId { get; set; }
    public string UserId { get; set; }
    public virtual ICollection<Transaction> Transactions { get; set; }
}

public class Transaction
{
    public long Id { get; set; }
    public long TenantId { get; set; }
    public string UserId { get; set; }
    public string AccountId { get; set; }
}

Я склонен видеть примеры использования TenantId для всего, что подпадает под арендатора.Я предполагаю, что это для безопасности, но мое естественное предположение было бы, что UserId будет достаточно.Например, хотя Транзакция находится на два уровня ниже Пользователя, я не считаю, что должен позволять любому, кто знает Идентификатор Транзакции, получать доступ к транзакции, не будучи также пользователем, который владеет учетной записью.

1 Ответ

0 голосов
/ 22 декабря 2018

Норма, которой мы следовали при добавлении TenantId, распространяется на все основные объекты.например, пользователи и учетные записи должны иметь TenantId.Поскольку транзакция является зависимой сущностью как для Пользователя, так и для Аккаунтов, и, следовательно, она не может быть получена без ссылки на базу (Аккаунт / Пользователь), нет мандата дляa TenantId.

Практическое правило состоит в том, чтобы классифицировать основной бизнес-объект, который будет сгруппирован / классифицирован арендатором.(Пользователь, Учетные записи и т. Д.), Чтобы при извлечении или обновлении данных в базе данных надлежащая фильтрация клиентов выполнялась до выполнения какой-либо операции над сопоставлением или дочерними таблицами.Поэтому, основываясь на объектах домена, пожалуйста, разумно включите столбец TenantId.

...