Где управлять доступом к заполнителю? Следуют правилам домена, управляемым доменомC#

Место общения программистов C#
Ответить Пред. темаСлед. тема
Anonymous
 Где управлять доступом к заполнителю? Следуют правилам домена, управляемым доменом

Сообщение Anonymous »

Следуя принципалам, управляемым доменом, < /p>
Допустим, мы создаем систему управления заказами B2B. Одним из требований является то, что для каждого клиента/порядка/заказа мы должны быть в состоянии назначить людей, которые будут управлять потоком заказа. В этом случае BWM является клиентом, заказ содержит два пункта: подшипники и крепежные элементы. Элон был назначен элементу заказа подшипников, чтобы он мог управлять только этим предметом, например, он может рассчитать цену предложения. < /P>
Код может выглядеть следующим образом: < /p>

Код: Выделить всё

public class Order
{
public CustomerId CustomerId { get; }
private List _items = [];
...
public ChangeOrderHeader() // Only Mark can do that
{
...
}
}
< /code>
public class OrderItem
{
public OrderId OrderId { get; }
...
public void PrepareOffer() // Available for Mark. Also for Elon if this is the bearing order item
{
...
}
}
< /code>
 Вопрос: < /strong> Как управлять проверкой разрешений в этом случае?public void PrepareOffer(User user)
{
EnsurePermissions(user); // Validation is in method, it also could be a policy
...
}
Проблема заключается в том, что вам нужно передавать информацию/политику пользователя на каждый метод внутри агрегата. Также в моем понимании домен должен заботиться о что/как , а не Кто .

Другой подход может быть подтверждением репозиции, например, при сохранении агрегата, мы можем проверить, что было изменено, и подтвердить ультрадации вызывающего.public class Repository(IUserAccessor userAccessor)
{
public Task Save(Order order)
{
var user = userAccessor.GetCurrentUser();
if(order.WasModified())
{
EnsureOrderPermissions(order, user);
}
...
}
}
< /code>
Этот подход не дает кодовой накладной расходы, но перемещает бизнес-логику к слою инфраструктуры. < /p>

Следующий подход, который приходит на мой взгляд, состоит в том, чтобы проверить разрешения пользователя в слои приложения, прежде чем называть методы домена.public OrderService(IUserAccessor userAccessor)
{
public void PrepareOffer(Order order, OrderLineId orderLineId)
{
var user = userAccessor.GetCurrentUser();
EnsureOrderLinePermissions(orderLineId, user);
order.PrepareOrder(orderLineId);
}
}
< /code>
В этом случае у нас есть больше кода, чем во втором подходе, но кажется логичным проверять разрешения на уровне приложений.>

Подробнее здесь: https://stackoverflow.com/questions/795 ... sign-rules
Реклама
Ответить Пред. темаСлед. тема

Быстрый ответ

Изменение регистра текста: 
Смайлики
:) :( :oops: :roll: :wink: :muza: :clever: :sorry: :angel: :read: *x)
Ещё смайлики…
   
К этому ответу прикреплено по крайней мере одно вложение.

Если вы не хотите добавлять вложения, оставьте поля пустыми.

Максимально разрешённый размер вложения: 15 МБ.

  • Похожие темы
    Ответы
    Просмотры
    Последнее сообщение

Вернуться в «C#»